Network Working Group D. Awduche
Request for Comments: 3272 Movaz Networks
Category: Informational A. Chiu
Celion Networks
A. Elwalid
I. Widjaja
Lucent Technologies
X. Xiao
Redback Networks
May 2002
Overview and Principles of Internet Traffic Engineering
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document.
このメモは、インターネットにトラフィックエンジニアリング（TE）の原則を説明しています。文書は、IPネットワーク内のトラフィックエンジニアリングを取り巻く問題のより良い理解を促進するため、およびインターネットのトラフィックエンジニアリング機能の開発のための共通基盤を提供することを意図しています。原則、アーキテクチャ、および運用IPネットワークの性能評価と性能の最適化のための方法論は、この文書を通して議論されています。
Table of Contents
目次
1.0 Introduction...................................................3
1.1 What is Internet Traffic Engineering?.......................4
1.2 Scope.......................................................7
1.3 Terminology.................................................8
2.0 Background....................................................11
2.1 Context of Internet Traffic Engineering....................12
2.2 Network Context............................................13
2.3 Problem Context............................................14
2.3.1 Congestion and its Ramifications......................16
2.4 Solution Context...........................................16
2.4.1 Combating the Congestion Problem......................18
2.5 Implementation and Operational Context.....................21
3.0 Traffic Engineering Process Model.............................21
3.1 Components of the Traffic Engineering Process Model........23
3.2 Measurement................................................23
3.3 Modeling, Analysis, and Simulation.........................24
3.4 Optimization...............................................25
4.0 Historical Review and Recent Developments.....................26
4.1 Traffic Engineering in Classical Telephone Networks........26
4.2 Evolution of Traffic Engineering in the Internet...........28
4.2.1 Adaptive Routing in ARPANET...........................28
4.2.2 Dynamic Routing in the Internet.......................29
4.2.3 ToS Routing...........................................30
4.2.4 Equal Cost Multi-Path.................................30
4.2.5 Nimrod................................................31
4.3 Overlay Model..............................................31
4.4 Constraint-Based Routing...................................32
4.5 Overview of Other IETF Projects Related to Traffic
Engineering................................................32
4.5.1 Integrated Services...................................32
4.5.2 RSVP..................................................33
4.5.3 Differentiated Services...............................34
4.5.4 MPLS..................................................35
4.5.5 IP Performance Metrics................................36
4.5.6 Flow Measurement......................................37
4.5.7 Endpoint Congestion Management........................37
4.6 Overview of ITU Activities Related to Traffic
Engineering................................................38
4.7 Content Distribution.......................................39
5.0 Taxonomy of Traffic Engineering Systems.......................40
5.1 Time-Dependent Versus State-Dependent......................40
5.2 Offline Versus Online......................................41
5.3 Centralized Versus Distributed.............................42
5.4 Local Versus Global........................................42
5.5 Prescriptive Versus Descriptive............................42
5.6 Open-Loop Versus Closed-Loop...............................43
5.7 Tactical vs Strategic......................................43
6.0 Recommendations for Internet Traffic Engineering..............43
6.1 Generic Non-functional Recommendations.....................44
6.2 Routing Recommendations....................................46
6.3 Traffic Mapping Recommendations............................48
6.4 Measurement Recommendations................................49
6.5 Network Survivability......................................50
6.5.1 Survivability in MPLS Based Networks..................52
6.5.2 Protection Option.....................................53
6.6 Traffic Engineering in Diffserv Environments...............54
6.7 Network Controllability....................................56
7.0 Inter-Domain Considerations...................................57
8.0 Overview of Contemporary TE Practices in Operational
IP Networks...................................................59
9.0 Conclusion....................................................63
10.0 Security Considerations......................................63
11.0 Acknowledgments..............................................63
12.0 References...................................................64
13.0 Authors' Addresses...........................................70
14.0 Full Copyright Statement.....................................71
This memo describes the principles of Internet traffic engineering. The objective of the document is to articulate the general issues and principles for Internet traffic engineering; and where appropriate to provide recommendations, guidelines, and options for the development of online and offline Internet traffic engineering capabilities and support systems.
このメモは、インターネットトラフィックエンジニアリングの原則を説明しています。文書の目的は、インターネットトラフィックエンジニアリングのための一般的な問題と原則を明確にあります。そして適切な場合には、オンラインとオフラインのインターネットトラフィックエンジニアリング機能と支援システムの開発のための推奨事項、ガイドライン、およびオプションを提供します。
This document can aid service providers in devising and implementing traffic engineering solutions for their networks. Networking hardware and software vendors will also find this document helpful in the development of mechanisms and support systems for the Internet environment that support the traffic engineering function.
この文書では、自社のネットワークのトラフィックエンジニアリングソリューションを考案し、実行中のサービスプロバイダを支援することができます。ハードウェアとソフトウェアのベンダーのネットワークもトラフィックエンジニアリング機能をサポートするインターネット環境のための仕組みと支援システムの開発において、この文書は参考になります。
This document provides a terminology for describing and understanding common Internet traffic engineering concepts. This document also provides a taxonomy of known traffic engineering styles. In this context, a traffic engineering style abstracts important aspects from a traffic engineering methodology. Traffic engineering styles can be viewed in different ways depending upon the specific context in which they are used and the specific purpose which they serve. The combination of styles and views results in a natural taxonomy of traffic engineering systems.
この文書は、一般的なインターネットトラフィックエンジニアリングの概念を説明し、理解するための用語を提供します。この文書では、既知のトラフィックエンジニアリングのスタイルの分類を提供します。この文脈では、トラフィックエンジニアリングのスタイルは、トラフィックエンジニアリングの方法論からの重要な側面を抽象化します。トラフィックエンジニアリングのスタイルは、それらが使用される特定の文脈と彼らが提供特定の目的に応じてさまざまな方法で表示することができます。スタイルとビューの組み合わせは、トラフィックエンジニアリングシステムの自然の分類になります。
Even though Internet traffic engineering is most effective when applied end-to-end, the initial focus of this document document is intra-domain traffic engineering (that is, traffic engineering within a given autonomous system). However, because a preponderance of Internet traffic tends to be inter-domain (originating in one autonomous system and terminating in another), this document provides an overview of aspects pertaining to inter-domain traffic engineering.
エンドツーエンド適用された場合、インターネットトラフィックエンジニアリングが最も効果的であるにも関わらず、このドキュメントの文書の最初の焦点は、ドメイン内のトラフィックエンジニアリングはある（つまり、与えられた自律システム内のトラフィックエンジニアリング）。インターネットトラフィックの圧倒的多数は、ドメイン間（1つの自律システムに由来し、他で終端）される傾向があるのでしかし、この文書は、ドメイン間のトラフィックエンジニアリングに関する側面の概要を説明します。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Internet traffic engineering is defined as that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks. Traffic Engineering encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic [RFC-2702, AWD2].
インターネットトラフィックエンジニアリングは、性能評価と運用IPネットワークのパフォーマンスの最適化の問題を扱うインターネットのネットワークエンジニアリングの側面として定義されます。トラフィックエンジニアリングは、インターネットトラフィック[RFC-2702、AWD2]の測定、特性評価、モデリング、および制御への技術および科学の原則の適用を包含する。
Enhancing the performance of an operational network, at both the traffic and resource levels, are major objectives of Internet traffic engineering. This is accomplished by addressing traffic oriented performance requirements, while utilizing network resources economically and reliably. Traffic oriented performance measures include delay, delay variation, packet loss, and throughput.
運用ネットワークのパフォーマンスを向上させる、両方のトラフィックおよびリソースレベルで、インターネットトラフィックエンジニアリングの主要な目的です。これは、経済的かつ確実にネットワークリソースを活用しながら、交通指向の性能要件に対処することによって達成されます。交通指向の業績指標は、遅延、遅延変動、パケット損失、およびスループットが含まれます。
An important objective of Internet traffic engineering is to facilitate reliable network operations [RFC-2702]. Reliable network operations can be facilitated by providing mechanisms that enhance network integrity and by embracing policies emphasizing network survivability. This results in a minimization of the vulnerability of the network to service outages arising from errors, faults, and failures occurring within the infrastructure.
インターネットトラフィックエンジニアリングの重要な目的は、信頼性の高いネットワーク運用[RFC-2702]容易にすることです。信頼性の高いネットワーク運用は、ネットワークの整合性を向上させる仕組みを提供することで、ネットワークの存続を重視政策を採用することによって容易にすることができます。これは、インフラストラクチャ内で発生したエラー、障害、および障害から生じるサービス停止にネットワークの脆弱性の最小化をもたらします。
The Internet exists in order to transfer information from source nodes to destination nodes. Accordingly, one of the most significant functions performed by the Internet is the routing of traffic from ingress nodes to egress nodes. Therefore, one of the most distinctive functions performed by Internet traffic engineering is the control and optimization of the routing function, to steer traffic through the network in the most effective way.
インターネットは、宛先ノードにソースノードから情報を転送するために存在します。したがって、インターネットによって実行される最も重要な機能の一つは、出口ノードへの入口ノードからのトラフィックのルーティングです。したがって、インターネット・トラフィック・エンジニアリングによって実行される最も特徴的な機能の一つは、最も効果的な方法でネットワークを介してトラフィックを操縦するために、ルーティング機能の制御および最適化です。
Ultimately, it is the performance of the network as seen by end users of network services that is truly paramount. This crucial point should be considered throughout the development of traffic engineering mechanisms and policies. The characteristics visible to end users are the emergent properties of the network, which are the characteristics of the network when viewed as a whole. A central goal of the service provider, therefore, is to enhance the emergent properties of the network while taking economic considerations into account.
本当に最優先されるネットワーク・サービスのエンドユーザーが見られるように最終的には、ネットワークのパフォーマンスです。この重要なポイントは、トラフィックエンジニアリングのメカニズムと政策の発展を通じて考慮されるべきです。エンド・ユーザーに表示特性が全体として見た場合にネットワークの特性であるネットワークの創発特性です。サービスプロバイダの中心的な目標は、したがって、考慮に経済的な考慮をしながらネットワークの創発的特性を向上させるためです。
The importance of the above observation regarding the emergent properties of networks is that special care must be taken when choosing network performance measures to optimize. Optimizing the wrong measures may achieve certain local objectives, but may have disastrous consequences on the emergent properties of the network and thereby on the quality of service perceived by end-users of network services.
ネットワークの創発的特性に関する上記の観察の重要性は、最適化するために、ネットワークのパフォーマンス指標を選択する際に特別な注意を払わなければならないということです。間違った対策を最適化することは、特定の地域の目標を達成することができるが、ネットワークの創発特性にすることにより、ネットワークサービスのエンドユーザーに知覚されるサービスの品質に悲惨な結果をもたらす可能性があります。
A subtle, but practical advantage of the systematic application of traffic engineering concepts to operational networks is that it helps to identify and structure goals and priorities in terms of enhancing the quality of service delivered to end-users of network services. The application of traffic engineering concepts also aids in the measurement and analysis of the achievement of these goals.
運用ネットワークへのトラフィックエンジニアリングの概念の体系的なアプリケーションの微妙な、しかし実用的な利点は、ネットワーク・サービスのエンドユーザに提供されるサービスの質を高めるという点で目標と優先順位を特定し、構造に役立ちますということです。トラフィックエンジニアリングの概念のアプリケーションは、これらの目標の達成の測定と分析に役立ちます。
The optimization aspects of traffic engineering can be achieved through capacity management and traffic management. As used in this document, capacity management includes capacity planning, routing control, and resource management. Network resources of particular interest include link bandwidth, buffer space, and computational resources. Likewise, as used in this document, traffic management includes (1) nodal traffic control functions such as traffic conditioning, queue management, scheduling, and (2) other functions that regulate traffic flow through the network or that arbitrate access to network resources between different packets or between different traffic streams.
トラフィックエンジニアリングの最適化の側面は、容量管理とトラフィック管理を介して達成することができます。本書で使用されるように、容量管理は、キャパシティプランニング、ルーティング制御、およびリソース管理を含みます。特に興味深いのネットワークリソースは、リンク帯域幅、バッファ・スペース、および計算リソースが含まれます。本書で使用されるように同様に、トラフィック管理は、トラフィックコンディショニング、キュー管理、スケジューリング、及びネットワーク又は別間のネットワーク資源への調停アクセスを介してトラフィックフローを規制（2）その他の機能として、（1）ノードのトラフィック制御機能を含みますパケットまたは異なるトラフィックストリーム間。
The optimization objectives of Internet traffic engineering should be viewed as a continual and iterative process of network performance improvement and not simply as a one time goal. Traffic engineering also demands continual development of new technologies and new methodologies for network performance enhancement.
インターネットトラフィックエンジニアリングの最適化の目的は、単純に1時間の目標としていないネットワーク・パフォーマンスの改善を継続的かつ反復的なプロセスと見るべきです。トラフィックエンジニアリングはまた、新しい技術やネットワークの性能向上のための新たな方法論の継続的な開発が求められています。
The optimization objectives of Internet traffic engineering may change over time as new requirements are imposed, as new technologies emerge, or as new insights are brought to bear on the underlying problems. Moreover, different networks may have different optimization objectives, depending upon their business models, capabilities, and operating constraints. The optimization aspects of traffic engineering are ultimately concerned with network control regardless of the specific optimization goals in any particular environment.
新たな洞察が根本的な問題に負担することになっているとして、インターネットトラフィックエンジニアリングの最適化の目的は、新たな要件が課されるように、新しい技術が出てくるように、時間の経過とともに変化する、またはことがあります。また、異なるネットワークは、彼らのビジネスモデル、機能、および動作上の制約に応じて、異なる最適化の目的を有することができます。トラフィックエンジニアリングの最適化の側面は、最終的には関係なく、任意の特定の環境における特定の最適化目標のネットワーク制御に関係しています。
Thus, the optimization aspects of traffic engineering can be viewed from a control perspective. The aspect of control within the Internet traffic engineering arena can be pro-active and/or reactive. In the pro-active case, the traffic engineering control system takes preventive action to obviate predicted unfavorable future network states. It may also take perfective action to induce a more desirable state in the future. In the reactive case, the control system responds correctively and perhaps adaptively to events that have already transpired in the network.
このように、トラフィックエンジニアリングの最適化の側面は、制御の観点から見ることができます。インターネット・トラフィック・エンジニアリング・アリーナ内のコントロールの側面は、プロアクティブおよび/または反応することができます。プロアクティブな場合、トラフィックエンジニアリング制御システムは、予測された不利な将来のネットワークの状態を回避するための予防措置をとります。また、将来的にはより望ましい状態を誘導するために完全化行動をとることがあります。反応の場合には、制御システムは、補正的、おそらく適応すでにネットワークに蒸散したイベントに応答します。
The control dimension of Internet traffic engineering responds at multiple levels of temporal resolution to network events. Certain aspects of capacity management, such as capacity planning, respond at very coarse temporal levels, ranging from days to possibly years. The introduction of automatically switched optical transport networks (e.g., based on the Multi-protocol Lambda Switching concepts) could significantly reduce the lifecycle for capacity planning by expediting provisioning of optical bandwidth. Routing control functions operate at intermediate levels of temporal resolution, ranging from milliseconds to days. Finally, the packet level processing functions (e.g., rate shaping, queue management, and scheduling) operate at very fine levels of temporal resolution, ranging from picoseconds to milliseconds while responding to the real-time statistical behavior of traffic. The subsystems of Internet traffic engineering control include: capacity augmentation, routing control, traffic control, and resource control (including control of service policies at network elements). When capacity is to be augmented for tactical purposes, it may be desirable to devise a deployment plan that expedites bandwidth provisioning while minimizing installation costs.
インターネットトラフィックエンジニアリングの制御寸法は、ネットワークイベントへの時間分解能の複数のレベルで応答します。そのようなキャパシティプランニングなどの容量管理の特定の態様は、日におそらく年に至るまで、非常に粗い時間レベルで応えます。 （コンセプトスイッチングマルチプロトコルラムダに基づいて、例えば、）自動的に切り替える光トランスポートネットワークの導入が著しく、光学帯域幅のプロビジョニングを促進することによって容量計画のためのライフサイクルを減らすことができます。経路制御機能は、ミリ秒から数日の範囲、時間分解能の中間レベルで動作します。最後に、パケットレベルの処理機能（例えば、レートシェーピング、キュー管理、スケジューリング）トラフィックのリアルタイム統計的挙動に対応しながらピコ秒からミリ秒の範囲、時間分解能の非常に細かいレベルで動作します。インターネットトラフィックエンジニアリング管理のサブシステムが含まれます：容量の増強、ルーティング制御、トラフィック制御、および（ネットワーク要素でのサービスポリシーの制御を含む）リソース制御を。容量は戦術的な目的のために、拡張する場合、設置コストを最小限に抑えながら、帯域幅のプロビジョニングを迅速に展開計画を考案することが望ましいことがあります。
Inputs into the traffic engineering control system include network state variables, policy variables, and decision variables.
トラフィックエンジニアリング制御システムへの入力は、ネットワークの状態変数、政策変数、および意思決定変数が含まれます。
One major challenge of Internet traffic engineering is the realization of automated control capabilities that adapt quickly and cost effectively to significant changes in a network's state, while still maintaining stability.
インターネットトラフィックエンジニアリングの1つの主要な課題は、まだ安定性を維持しながら、迅速に対応し、ネットワークの状態で重大な変化にコスト効率自動制御機能の実現です。
Another critical dimension of Internet traffic engineering is network performance evaluation, which is important for assessing the effectiveness of traffic engineering methods, and for monitoring and verifying compliance with network performance goals. Results from performance evaluation can be used to identify existing problems, guide network re-optimization, and aid in the prediction of potential future problems.
インターネットトラフィックエンジニアリングのもう一つの限界寸法は、トラフィックエンジニアリング手法の有効性を評価するための、およびネットワークパフォーマンスの目標の遵守を監視し、検証するために重要であるネットワークの性能評価、です。性能評価の結果は、既存の問題、ガイドネットワークの再最適化、および潜在的な将来の問題の予測で援助を識別するために使用することができます。
Performance evaluation can be achieved in many different ways. The most notable techniques include analytical methods, simulation, and empirical methods based on measurements. When analytical methods or simulation are used, network nodes and links can be modeled to capture relevant operational features such as topology, bandwidth, buffer space, and nodal service policies (link scheduling, packet prioritization, buffer management, etc.). Analytical traffic models can be used to depict dynamic and behavioral traffic characteristics, such as burstiness, statistical distributions, and dependence.
性能評価は、多くの異なる方法で達成することができます。最も注目すべき技術は、分析方法、シミュレーション、および測定値に基づいて経験的な方法が挙げられます。分析方法やシミュレーションが使用されている場合は、ネットワーク・ノードとリンクは、そのようなトポロジー、帯域幅、バッファ・スペース、および結節サービスポリシー（リンクスケジューリング、パケットの優先順位付け、バッファ管理、など）などの関連業務の機能をキャプチャするためにモデル化することができます。分析トラフィックモデルは、バースト、統計分布、および依存性などの動的および行動トラフィック特性を示すために使用することができます。
Performance evaluation can be quite complicated in practical network contexts. A number of techniques can be used to simplify the analysis, such as abstraction, decomposition, and approximation. For example, simplifying concepts such as effective bandwidth and effective buffer [Elwalid] may be used to approximate nodal behaviors at the packet level and simplify the analysis at the connection level. Network analysis techniques using, for example, queuing models and approximation schemes based on asymptotic and decomposition techniques can render the analysis even more tractable. In particular, an emerging set of concepts known as network calculus [CRUZ] based on deterministic bounds may simplify network analysis relative to classical stochastic techniques. When using analytical techniques, care should be taken to ensure that the models faithfully reflect the relevant operational characteristics of the modeled network entities.
性能評価は、実用的なネットワークのコンテキストで非常に複雑になることができます。多くの技術は、抽象化、分解、及び近似として、分析を単純化するために使用することができます。例えば、そのような効果的な帯域幅と実効バッファ[Elwalid]として簡略化の概念は、パケットレベルでのノードの挙動を近似し、接続レベルでの分析を簡単にするために使用されてもよいです。使用したネットワーク解析技術は、例えば、漸近分解技術に基づいたモデルと近似スキームをキューイングすることは、より扱いやすい解析をレンダリングすることができます。具体的には、決定論的境界に基づいて、ネットワーク計算として知られている概念の新たなセット[クルーズ]古典的な確率論的技術にネットワーク解析を相対的に単純化することができます。分析技術を使用する場合は、注意がモデルを忠実にモデル化されたネットワークエンティティの関連する動作特性を反映するように注意する必要があります。
Simulation can be used to evaluate network performance or to verify and validate analytical approximations. Simulation can, however, be computationally costly and may not always provide sufficient insights. An appropriate approach to a given network performance evaluation problem may involve a hybrid combination of analytical techniques, simulation, and empirical methods.
シミュレーションは、ネットワークのパフォーマンスを評価するために、または分析近似値を検証し、検証するために使用することができます。シミュレーションは、しかし、計算上コストがかかることがあり、常に十分な洞察を提供することはできません。与えられたネットワーク性能評価の問題に対する適切なアプローチは、分析技術、シミュレーション、経験的な方法のハイブリッド組み合わせを含むことができます。
As a general rule, traffic engineering concepts and mechanisms must be sufficiently specific and well defined to address known requirements, but simultaneously flexible and extensible to accommodate unforeseen future demands.
原則として、トラフィックエンジニアリングの概念とメカニズムは、不測の将来の需要に対応するのに十分に特異的であり、周知の要件に対処するために定義され、しかし同時に、柔軟で拡張可能でなければなりません。
The scope of this document is intra-domain traffic engineering; that is, traffic engineering within a given autonomous system in the Internet. This document will discuss concepts pertaining to intra-domain traffic control, including such issues as routing control, micro and macro resource allocation, and the control coordination problems that arise consequently.
この文書の範囲は、ドメイン内のトラフィックエンジニアリングです。それは、インターネット内の指定された自律システム内のトラフィックエンジニアリング、です。この文書では、ルーティング制御、ミクロとマクロのリソース割り当て、その結果発生する制御協調問題などの問題を含め、ドメイン内のトラフィック制御、に関連する概念について説明します。
This document will describe and characterize techniques already in use or in advanced development for Internet traffic engineering. The way these techniques fit together will be discussed and scenarios in which they are useful will be identified.
この文書では、記述し、すでに使用中またはインターネットトラフィックエンジニアリングのための高度な開発の技術を特徴づけるます。これらの技術を組み合わせる方法が議論されると、彼らが有用であるシナリオは識別されます。
While this document considers various intra-domain traffic engineering approaches, it focuses more on traffic engineering with MPLS. Traffic engineering based upon manipulation of IGP metrics is not addressed in detail. This topic may be addressed by other working group document(s).
この文書は、さまざまなドメイン内の交通工学的アプローチを考慮しながら、それはMPLSとトラフィックエンジニアリングの詳細を焦点を当てています。 IGPメトリックの操作に基づいてトラフィックエンジニアリングを詳細に対処されていません。このトピックでは、他のワーキンググループのドキュメント（S）によって対処することができます。
Although the emphasis is on intra-domain traffic engineering, in Section 7.0, an overview of the high level considerations pertaining to inter-domain traffic engineering will be provided. Inter-domain Internet traffic engineering is crucial to the performance enhancement of the global Internet infrastructure.
重点は、ドメイン内のトラフィックエンジニアリング上ですが、セクション7.0で、ドメイン間のトラフィックエンジニアリングに関するハイレベルの考慮事項の概要について説明します。ドメイン間のインターネットトラフィックエンジニアリングは、グローバルなインターネットインフラの性能向上に不可欠です。
Whenever possible, relevant requirements from existing IETF documents and other sources will be incorporated by reference.
可能な限り、既存のIETFのドキュメントや他のソースからの関連する要件は、参考として援用されます。
This subsection provides terminology which is useful for Internet traffic engineering. The definitions presented apply to this document. These terms may have other meanings elsewhere.
ここでは、インターネットトラフィックエンジニアリングのために有用である用語を提供します。提示した定義は、この文書に適用されます。これらの用語は、他の場所で他の意味を有していてもよいです。
- Baseline analysis: A study conducted to serve as a baseline for comparison to the actual behavior of the network.
- ベースラインの分析：ネットワークの実際の挙動との比較のためのベースラインとして機能するように行われた研究。
- Busy hour: A one hour period within a specified interval of time (typically 24 hours) in which the traffic load in a network or sub-network is greatest.
- ビジー時間：ネットワークまたはサブネットワーク内のトラフィック負荷が最大である時間の特定の間隔（通常24時間）以内に1時間の期間。
- Bottleneck: A network element whose input traffic rate tends to be greater than its output rate.
- ボトルネック：その入力トラフィックレートが出力レートよりも大きくなる傾向にあるネットワークエレメント。
- Congestion: A state of a network resource in which the traffic incident on the resource exceeds its output capacity over an interval of time.
- 輻輳：リソース上の交通事象は、時間の間隔にわたって、その出力容量を超えたネットワーク資源の状態。
- Congestion avoidance: An approach to congestion management that attempts to obviate the occurrence of congestion.
- 輻輳回避：輻輳の発生を回避しようとする輻輳管理のアプローチ。
- Congestion control: An approach to congestion management that attempts to remedy congestion problems that have already occurred.
- 輻輳制御：既に発生している渋滞の問題を解決しようとする輻輳管理へのアプローチ。
- Constraint-based routing: A class of routing protocols that take specified traffic attributes, network constraints, and policy constraints into account when making routing decisions. Constraint-based routing is applicable to traffic aggregates as well as flows. It is a generalization of QoS routing.
- 制約ベースのルーティング：ルーティングの決定をするときに指定したトラフィックは、アカウントに、ネットワークの制約、およびポリシー制約属性取るルーティングプロトコルのクラス。制約ベースのルーティングは、トラフィックに適用される集約するだけでなく、流れています。これは、QoSルーティングの一般化です。
- Demand side congestion management: A congestion management scheme that addresses congestion problems by regulating or conditioning offered load.
- 需要側の輻輳管理：与えられた負荷を調整又は調整によって輻輳問題に対処し、輻輳管理スキーム。
- Effective bandwidth: The minimum amount of bandwidth that can be assigned to a flow or traffic aggregate in order to deliver 'acceptable service quality' to the flow or traffic aggregate.
- 有効帯域幅：フローまたはトラフィック集合に「許容されるサービスの品質」を提供するために、フローまたはトラフィック集合に割り当てることができる帯域幅の最小量。
- Egress traffic: Traffic exiting a network or network element.
- 出力トラフィック：トラフィックがネットワークまたはネットワーク要素を出て行きます。
- Hot-spot: A network element or subsystem which is in a state of congestion.
- ホットスポット：輻輳状態にあるネットワーク要素またはサブシステム。
- Ingress traffic: Traffic entering a network or network element.
- 入力トラフィック：トラフィックがネットワークまたはネットワーク要素に入ります。
- Inter-domain traffic: Traffic that originates in one Autonomous system and terminates in another.
- ドメイン間のトラフィック：1つの自律システム内で発生し、他で終了するトラフィック。
- Loss network: A network that does not provide adequate buffering for traffic, so that traffic entering a busy resource within the network will be dropped rather than queued.
- 損失ネットワーク：トラフィックがネットワーク内で忙しいリソースを入力するように、トラフィックのための十分なバッファリングを提供していないネットワークはドロップではなく、キューに入れられます。
- Metric: A parameter defined in terms of standard units of measurement.
- メトリック：測定の標準単位で定義されたパラメータ。
- Measurement Methodology: A repeatable measurement technique used to derive one or more metrics of interest.
- 測定方法：目的の1つの以上のメトリックを導出するために使用される反復測定技術。
- Network Survivability: The capability to provide a prescribed level of QoS for existing services after a given number of failures occur within the network.
- ネットワーク耐障害：障害の与えられた数は、ネットワーク内で発生した後、既存のサービスのためのQoSの所定のレベルを提供する機能。
- Offline traffic engineering: A traffic engineering system that exists outside of the network.
- オフライントラフィックエンジニアリング：ネットワークの外部に存在するトラフィックエンジニアリングシステム。
- Online traffic engineering: A traffic engineering system that exists within the network, typically implemented on or as adjuncts to operational network elements.
- オンライントラフィックエンジニアリング：、ネットワーク内に存在する、一般的にまたは運用ネットワーク要素への補助剤として実装トラフィックエンジニアリングシステム。
- Performance measures: Metrics that provide quantitative or qualitative measures of the performance of systems or subsystems of interest.
- パフォーマンス対策：システムや関心のサブシステムの性能を定量的または定性的な対策を提供するメトリック。
- Performance management: A systematic approach to improving effectiveness in the accomplishment of specific networking goals related to performance improvement.
- パフォーマンス管理：パフォーマンスの改善に関連する特定のネットワークの目標の達成に有効性を改善するための体系的なアプローチ。
- Performance Metric: A performance parameter defined in terms of standard units of measurement.
- パフォーマンスメトリック：測定の標準単位で定義された性能パラメータ。
- Provisioning: The process of assigning or configuring network resources to meet certain requests.
- プロビジョニング：割り当てまたは特定の要求を満たすためにネットワークリソースを構成するプロセス。
- QoS routing: Class of routing systems that selects paths to be used by a flow based on the QoS requirements of the flow.
- QoSのルーティング：ルーティングシステムのクラスフローのQoS要件に基づいて、フローが使用するパスを選択します。
- Service Level Agreement: A contract between a provider and a customer that guarantees specific levels of performance and reliability at a certain cost.
- サービスレベルアグリーメント：プロバイダと一定のコストでパフォーマンスと信頼性の特定のレベルを保証し、顧客との間の契約。
- Stability: An operational state in which a network does not oscillate in a disruptive manner from one mode to another mode.
- 安定性：ネットワークが一つのモードから他のモードに破壊様式で振動しないような運転状態。
- Supply side congestion management: A congestion management scheme that provisions additional network resources to address existing and/or anticipated congestion problems.
- 供給側の輻輳管理：既存および/または予想される渋滞の問題に対処するための引当金の追加ネットワークリソース輻輳管理スキーム。
- Transit traffic: Traffic whose origin and destination are both outside of the network under consideration.
- トランジットトラフィック：その出発地と目的地検討中のネットワークの両方の外側にあるトラフィック。
- Traffic characteristic: A description of the temporal behavior or a description of the attributes of a given traffic flow or traffic aggregate.
- トラフィック特性：時間的挙動の説明や特定のトラフィックフローまたはトラフィック集約の属性の説明。
- Traffic engineering system: A collection of objects, mechanisms, and protocols that are used conjunctively to accomplish traffic engineering objectives.
- トラフィックエンジニアリングシステム：トラフィックエンジニアリングの目的を達成するために結合的に使用されているオブジェクト、メカニズム、およびプロトコルの集合。
- Traffic flow: A stream of packets between two end-points that can be characterized in a certain way. A micro-flow has a more specific definition: A micro-flow is a stream of packets with the same source and destination addresses, source and destination ports, and protocol ID.
- トラフィックフロー：特定の方法で特徴付けることができる2つのエンドポイント間のパケットの流れ。マイクロ流は、より具体的な定義を有するマイクロ流は、同一の送信元アドレスと宛先アドレス、送信元ポートと宛先ポート、及びプロトコルIDを持つパケットのストリームです。
- Traffic intensity: A measure of traffic loading with respect to a resource capacity over a specified period of time. In classical telephony systems, traffic intensity is measured in units of Erlang.
- トラフィック強度：指定された期間にわたってリソース容量に対するトラフィック負荷の尺度。古典的な電話システムにおいて、トラフィック強度はアーランの単位で測定されます。
- Traffic matrix: A representation of the traffic demand between a set of origin and destination abstract nodes. An abstract node can consist of one or more network elements.
- トラフィックマトリクス：出発地と目的地の抽象ノードのセット間のトラフィック需要の表現。抽象ノードは、1つのまたは複数のネットワーク要素から成ることができます。
- Traffic monitoring: The process of observing traffic characteristics at a given point in a network and collecting the traffic information for analysis and further action.
- トラフィックのモニタリング：ネットワーク内の所与の点でのトラフィック特性を観察し、分析し、さらにアクションのトラフィック情報を収集するプロセス。
- Traffic trunk: An aggregation of traffic flows belonging to the same class which are forwarded through a common path. A traffic trunk may be characterized by an ingress and egress node, and a set of attributes which determine its behavioral characteristics and requirements from the network.
- 交通トランク：トラフィックの集約共通パスを介して転送されている同じクラスに属すると流れます。トラフィックトランクは、入力および出力ノード、およびネットワークからその動作特性および要件を決定する属性の組によって特徴付けることができます。
The Internet has quickly evolved into a very critical communications infrastructure, supporting significant economic, educational, and social activities. Simultaneously, the delivery of Internet communications services has become very competitive and end-users are demanding very high quality service from their service providers. Consequently, performance optimization of large scale IP networks, especially public Internet backbones, have become an important problem. Network performance requirements are multi-dimensional, complex, and sometimes contradictory; making the traffic engineering problem very challenging.
インターネットは急速に重要な、経済、教育、社会活動を支援する、非常に重要な通信インフラへと進化してきました。同時に、インターネット通信サービスの配信は非常に競争力となっており、エンドユーザーは、サービス・プロバイダーから非常に高品質のサービスを求めています。その結果、大規模IPネットワークのパフォーマンスの最適化、特に公共のインターネットバックボーンは、重要な問題となっています。ネットワーク性能要件は、多次元の複雑な、そして時には矛盾しています。トラフィックエンジニアリングの問題は非常に挑戦的な作り。
The network must convey IP packets from ingress nodes to egress nodes efficiently, expeditiously, and economically. Furthermore, in a multiclass service environment (e.g., Diffserv capable networks), the resource sharing parameters of the network must be appropriately determined and configured according to prevailing policies and service models to resolve resource contention issues arising from mutual interference between packets traversing through the network. Thus, consideration must be given to resolving competition for network resources between traffic streams belonging to the same service class (intra-class contention resolution) and traffic streams belonging to different classes (inter-class contention resolution).
ネットワークを効率的、迅速、かつ経済的に出口ノードへの入口ノードからのIPパケットを伝えなければなりません。さらに、マルチクラスサービス環境（例えば、Diffservのできるネットワーク）において、ネットワークのリソース共有パラメータが適切にネットワークを介して通過するパケットとの間の相互干渉から生じるリソース競合問題を解決するために有力なポリシーおよびサービス・モデルに応じて決定して設定する必要があり。このように、考慮事項は、同じサービスクラスに属するトラフィックストリーム（クラス内の競合解決）と異なるクラス（クラス間の競合の解決）に属するトラフィックストリーム間のネットワークリソースの競合の解決に与えられなければなりません。
The context of Internet traffic engineering pertains to the scenarios where traffic engineering is used. A traffic engineering methodology establishes appropriate rules to resolve traffic performance issues occurring in a specific context. The context of Internet traffic engineering includes:
インターネットトラフィックエンジニアリングのコンテキストは、トラフィックエンジニアリングが使用されているシナリオに関係します。トラフィックエンジニアリングの方法論は、特定のコンテキストで発生するトラフィックのパフォーマンスの問題を解決するために、適切なルールを確立します。インターネットトラフィックエンジニアリングのコンテキストが含まれています：
(1) A network context defining the universe of discourse, and in particular the situations in which the traffic engineering problems occur. The network context includes network structure, network policies, network characteristics, network constraints, network quality attributes, and network optimization criteria.
（1）ネットワークコンテキストが論議領域を定義し、特定の状況とは、トラフィックエンジニアリングの問題が発生します。ネットワークコンテキストは、ネットワーク構造、ネットワークポリシー、ネットワーク特性、ネットワークの制約、ネットワーク品質属性、およびネットワークの最適化基準を含んでいます。
(2) A problem context defining the general and concrete issues that traffic engineering addresses. The problem context includes identification, abstraction of relevant features, representation, formulation, specification of the requirements on the solution space, and specification of the desirable features of acceptable solutions.
（2）トラフィックエンジニアリングアドレスという一般的かつ具体的な問題を定義し、問題のコンテキストを。問題のコンテキストは、許容可能なソリューションの望ましい特徴の識別、関連する特徴を抽象化、表現、製剤、解空間上の要件の仕様、及び仕様を含みます。
(3) A solution context suggesting how to address the issues identified by the problem context. The solution context includes analysis, evaluation of alternatives, prescription, and resolution.
（3）問題の文脈で特定された問題に対処する方法を示唆ソリューション・コンテキスト。ソリューションのコンテキストが分析、代替案の評価、処方、および解像度が含まれています。
(4) An implementation and operational context in which the solutions are methodologically instantiated. The implementation and operational context includes planning, organization, and execution.
（4）溶液を方法論的にインスタンス化された実装と動作コンテキスト。実装と運用状況は、計画、組織、および実行を含んでいます。
The context of Internet traffic engineering and the different problem scenarios are discussed in the following subsections.
インターネットトラフィックエンジニアリングと異なる問題のシナリオのコンテキストは、以下のサブセクションで説明されています。
IP networks range in size from small clusters of routers situated within a given location, to thousands of interconnected routers, switches, and other components distributed all over the world.
IPネットワークは、世界中に分布する相互接続されたルータ、スイッチ、および他の構成要素の数千に、与えられた場所内に位置するルータの小さなクラスターのサイズの範囲です。
Conceptually, at the most basic level of abstraction, an IP network can be represented as a distributed dynamical system consisting of: (1) a set of interconnected resources which provide transport services for IP traffic subject to certain constraints, (2) a demand system representing the offered load to be transported through the network, and (3) a response system consisting of network processes, protocols, and related mechanisms which facilitate the movement of traffic through the network [see also AWD2].
特定の制約へのIPトラフィック対象のトランスポート・サービスを提供する相互接続されたリソースの（1）セット、（2）デマンドシステム：概念的には、抽象化の最も基本的なレベルで、IPネットワークは、以下からなる分散力学系として表すことができます。ネットワークを介して輸送されるために提供負荷、およびネットワーク・プロセス、プロトコル、およびネットワークを介したトラフィックの移動を容易にする関連機構からなる（3）応答システムを表すと、[AWD2も参照します]。
The network elements and resources may have specific characteristics restricting the manner in which the demand is handled. Additionally, network resources may be equipped with traffic control mechanisms superintending the way in which the demand is serviced. Traffic control mechanisms may, for example, be used to control various packet processing activities within a given resource, arbitrate contention for access to the resource by different packets, and regulate traffic behavior through the resource. A configuration management and provisioning system may allow the settings of the traffic control mechanisms to be manipulated by external or internal entities in order to exercise control over the way in which the network elements respond to internal and external stimuli.
ネットワーク要素とリソース要求が処理される方法を制限する特定の特性を有することができます。さらに、ネットワークリソースは、要求がサービスされる方法をsuperintendingトラフィック制御機構を備えていてもよいです。トラフィック制御機構は、例えば、所与のリソース内の様々なパケット処理活動を制御する異なるパケットが、リソースへのアクセスの競合を調停し、リソースを介してトラフィック動作を調節するために使用されてもよいです。構成管理およびプロビジョニングシステムは、トラフィック制御機構の設定は、ネットワーク要素が内部および外部刺激に応答する方法の制御を行使するために外部または内部のエンティティによって操作することを可能にすることができます。
The details of how the network provides transport services for packets are specified in the policies of the network administrators and are installed through network configuration management and policy based provisioning systems. Generally, the types of services provided by the network also depends upon the technology and characteristics of the network elements and protocols, the prevailing service and utility models, and the ability of the network administrators to translate policies into network configurations.
ネットワークはパケットのための輸送サービスを提供する方法の詳細については、ネットワーク管理者のポリシーで指定されており、ネットワーク構成管理とポリシーベースのプロビジョニングシステムを使用してインストールされています。一般的に、ネットワークが提供するサービスの種類も、技術とネットワーク要素とプロトコルの特性、現行のサービスおよびユーティリティモデル、およびネットワーク構成にポリシーを変換するネットワーク管理者の能力に依存します。
Contemporary Internet networks have three significant characteristics: (1) they provide real-time services, (2) they have become mission critical, and (3) their operating environments are very dynamic. The dynamic characteristics of IP networks can be attributed in part to fluctuations in demand, to the interaction between various network protocols and processes, to the rapid evolution of the infrastructure which demands the constant inclusion of new technologies and new network elements, and to transient and persistent impairments which occur within the system.
（1）彼らは（2）彼らはミッションクリティカルとなっている、リアルタイムサービスを提供し、（3）その動作環境は非常に動的である：現代のインターネットのネットワークは、3つの重要な特性を持っています。 IPネットワークの動的特性は、新しい技術と新しいネットワーク要素の定数を含めることを要求するインフラの急速な進化に、様々なネットワークプロトコルとプロセスとの間の相互作用のために、需要の変動に部分的に起因し得る、および一過することとシステム内で発生する永続的な障害。
Packets contend for the use of network resources as they are conveyed through the network. A network resource is considered to be congested if the arrival rate of packets exceed the output capacity of the resource over an interval of time. Congestion may result in some of the arrival packets being delayed or even dropped.
彼らは、ネットワークを介して搬送されるようパケットは、ネットワークリソースの使用を争います。ネットワークリソースは、パケットの到着率は、時間の間隔にわたってリソースの出力容量を超えた場合に輻輳していると考えられます。輻輳が遅延したりしても破棄され、到着パケットの一部になることがあります。
Congestion increases transit delays, delay variation, packet loss, and reduces the predictability of network services. Clearly, congestion is a highly undesirable phenomenon.
輻輳は、伝送遅延、遅延変動、パケット損失が増加し、ネットワークサービスの予測可能性を低減します。明らかに、輻輳が非常に望ましくない現象です。
Combating congestion at a reasonable cost is a major objective of Internet traffic engineering.
合理的なコストで混雑との闘いは、インターネットトラフィックエンジニアリングの主要な目的です。
Efficient sharing of network resources by multiple traffic streams is a basic economic premise for packet switched networks in general and for the Internet in particular. A fundamental challenge in network operation, especially in a large scale public IP network, is to increase the efficiency of resource utilization while minimizing the possibility of congestion.
複数のトラフィックストリームにより、ネットワークリソースの効率的な共有は、パケットのための基本的な経済前提は、一般的に、特にインターネットのために交換ネットワークです。ネットワーク運用における基本的な課題は、特に大規模なパブリックIPネットワークでは、輻輳の可能性を最小限に抑えながら、リソースの利用効率を高めることです。
Increasingly, the Internet will have to function in the presence of different classes of traffic with different service requirements. The advent of Differentiated Services [RFC-2475] makes this requirement particularly acute. Thus, packets may be grouped into behavior aggregates such that each behavior aggregate may have a common set of behavioral characteristics or a common set of delivery requirements. In practice, the delivery requirements of a specific set of packets may be specified explicitly or implicitly. Two of the most important traffic delivery requirements are capacity constraints and QoS constraints.
ますます、インターネットは異なるサービス要件を持つトラフィックの異なるクラスの存在で機能する必要があります。差別化サービス[RFC-2475]の出現は、この要件は特に深刻になります。したがって、パケットは、各行動集合が行動特性の共通のセットまたは送達要件の共通セットを有することができるように挙動集合体にグループ化することができます。実際には、パケットの特定のセットの配信要件は、明示的または暗黙的に指定することができます。最も重要なトラフィックの配信要件の二つは、容量制約およびQoS制約されています。
Capacity constraints can be expressed statistically as peak rates, mean rates, burst sizes, or as some deterministic notion of effective bandwidth. QoS requirements can be expressed in terms of (1) integrity constraints such as packet loss and (2) in terms of temporal constraints such as timing restrictions for the delivery of each packet (delay) and timing restrictions for the delivery of consecutive packets belonging to the same traffic stream (delay variation).
容量制約は、統計学的にピーク速度、平均速度、バーストサイズとして、または効果的な帯域幅の一部の決定論的概念として表現することができます。 QoS要件は、各パケットの送出タイミング制約（遅延）に属する連続したパケットの送達のためのタイミング制約として時間的制約の観点から、このようなパケットロス及び（2）（1）整合性制約の観点で表すことができます。同じトラフィックストリーム（遅延変動）。
Fundamental problems exist in association with the operation of a network described by the simple model of the previous subsection. This subsection reviews the problem context in relation to the traffic engineering function.
根本的な問題は、前のサブセクションの単純なモデルで説明されたネットワークの動作に関連して存在します。ここでは、トラフィックエンジニアリング機能に関連する問題のコンテキストを見直しています。
The identification, abstraction, representation, and measurement of network features relevant to traffic engineering is a significant issue.
トラフィックエンジニアリングに関連する識別、抽象化、表現、およびネットワーク機能の測定は重要な問題です。
One particularly important class of problems concerns how to explicitly formulate the problems that traffic engineering attempts to solve, how to identify the requirements on the solution space, how to specify the desirable features of good solutions, how to actually solve the problems, and how to measure and characterize the effectiveness of the solutions.
特に重要な1つの明示的にトラフィックエンジニアリングがどのように実際に問題を解決するために、良い解決策の望ましい特徴を指定する方法、解空間上の要件を特定する方法を、解決しようとする問題を定式化するためにどのような問題への懸念のクラス、そしてどのようにソリューションの有効性を測定し、特徴づけます。
Another class of problems concerns how to measure and estimate relevant network state parameters. Effective traffic engineering relies on a good estimate of the offered traffic load as well as a view of the underlying topology and associated resource constraints. A network-wide view of the topology is also a must for offline planning.
問題の別のクラスは、計測および関連するネットワーク状態パラメータを推定する方法に関するものです。効果的なトラフィックエンジニアリングは、提供されたトラフィック負荷の良好な推定値だけでなく、根本的なトポロジーおよび関連するリソースの制約のビューに依存しています。トポロジのネットワーク全体のビューは、オフライン計画のための絶対必要です。
Still another class of problems concerns how to characterize the state of the network and how to evaluate its performance under a variety of scenarios. The performance evaluation problem is two-fold. One aspect of this problem relates to the evaluation of the system level performance of the network. The other aspect relates to the evaluation of the resource level performance, which restricts attention to the performance analysis of individual network resources. In this memo, we refer to the system level characteristics of the network as the "macro-states" and the resource level characteristics as the "micro-states." The system level characteristics are also known as the emergent properties of the network as noted earlier. Correspondingly, we shall refer to the traffic engineering schemes dealing with network performance optimization at the systems level as "macro-TE" and the schemes that optimize at the individual resource level as "micro-TE." Under certain circumstances, the system level performance can be derived from the resource level performance using appropriate rules of composition, depending upon the particular performance measures of interest.
それでも問題の別のクラスは、ネットワークの状態を特徴付ける方法と、様々なシナリオの下でその性能を評価する方法に関するものです。性能評価の問題が二つあります。この問題の一つの態様は、ネットワークのシステムレベル性能の評価に関する。他の態様は、個々のネットワークリソースの性能解析に注意を制限するリソース・レベルの性能の評価に関する。この文書では、「マクロ状態」とのようなリソース・レベルの特性のようなネットワークのシステムレベル特性を参照して、「マイクロ状態。」前述したように、システム・レベルの特性は、ネットワークの創発特性として知られています。それに対応して、我々は「マクロ-TE」などのシステムレベルでのネットワークパフォーマンスの最適化を扱うトラフィックエンジニアリングスキームとなどの個々のリソースレベルでの最適化手法を指すものとする「マイクロ-TE。」特定の状況下では、システムレベルの性能は、対象の特定の性能測定値に応じて、組成物の適切なルールを使用して、リソースレベルの性能に由来することができます。
Another fundamental class of problems concerns how to effectively optimize network performance. Performance optimization may entail translating solutions to specific traffic engineering problems into network configurations. Optimization may also entail some degree of resource management control, routing control, and/or capacity augmentation.
問題のもう一つの基本的なクラスには、効果的にネットワークのパフォーマンスを最適化する方法に関するものです。パフォーマンスの最適化は、ネットワーク構成に特定のトラフィックエンジニアリング問題の解決策を翻訳伴ってもよいです。最適化は、リソース管理制御、経路制御、及び/又は容量増大をある程度必要とすることができます。
As noted previously, congestion is an undesirable phenomena in operational networks. Therefore, the next subsection addresses the issue of congestion and its ramifications within the problem context of Internet traffic engineering.
前述のように、輻輳は、運用ネットワークでは望ましくない現象です。したがって、次のサブセクションでは、渋滞やインターネットトラフィックエンジニアリングの問題のコンテキスト内でその波及効果の問題を解決します。
Congestion is one of the most significant problems in an operational IP context. A network element is said to be congested if it experiences sustained overload over an interval of time. Congestion almost always results in degradation of service quality to end users. Congestion control schemes can include demand side policies and supply side policies. Demand side policies may restrict access to congested resources and/or dynamically regulate the demand to alleviate the overload situation. Supply side policies may expand or augment network capacity to better accommodate offered traffic. Supply side policies may also re-allocate network resources by redistributing traffic over the infrastructure. Traffic redistribution and resource re-allocation serve to increase the 'effective capacity' seen by the demand.
輻輳が運用IPの文脈の中で最も重要な問題の一つです。ネットワーク要素は、それが時間の間隔で持続的な過負荷が発生した場合、輻輳していると言われています。混雑はほとんどの場合、エンドユーザーへのサービス品質の低下につながります。輻輳制御方式は、需要サイドの政策と供給側のポリシーを含めることができます。需要側の政策は、混雑したリソースへのアクセスを制限および/または動的に過負荷状態を緩和する需要を調節することができます。サプライサイド政策展開またはより良い提供されたトラフィックに対応するためにネットワーク容量を拡張することがあります。サプライサイド政策も、インフラストラクチャ上のトラフィックを再分配することにより、ネットワークリソースを再割り当てることができます。トラフィック再配分と資源の再配分は需要から見た「効果的な能力」を高めるのに役立ちます。
The emphasis of this memo is primarily on congestion management schemes falling within the scope of the network, rather than on congestion management systems dependent upon sensitivity and adaptivity from end-systems. That is, the aspects that are considered in this memo with respect to congestion management are those solutions that can be provided by control entities operating on the network and by the actions of network administrators and network operations systems.
このメモの重点はむしろエンドシステムから感度および適応に依存輻輳管理システムよりも、ネットワークの範囲内に輻輳管理方式に主にあります。つまり、輻輳管理に関してこのメモで考慮される態様は、ネットワーク上で動作する制御エンティティにより、ネットワーク管理者やネットワーク運用システムの動作によって提供することができるそれらの溶液です。
The solution context for Internet traffic engineering involves analysis, evaluation of alternatives, and choice between alternative courses of action. Generally the solution context is predicated on making reasonable inferences about the current or future state of the network, and subsequently making appropriate decisions that may involve a preference between alternative sets of action. More specifically, the solution context demands reasonable estimates of traffic workload, characterization of network state, deriving solutions to traffic engineering problems which may be implicitly or explicitly formulated, and possibly instantiating a set of control actions. Control actions may involve the manipulation of parameters associated with routing, control over tactical capacity acquisition, and control over the traffic management functions.
インターネットトラフィックエンジニアリングのためのソリューションのコンテキストが分析、代替案の評価、およびアクションの代替コースの間の選択を必要とします。一般に、溶液コンテキストは、ネットワークの現在または将来の状態について合理的な推論を行うこと、およびその後のアクションの別のセットの間の優先順位を含むことができる適切な意思決定に基づいています。具体的には、ソリューション・コンテキストは、トラフィックの負荷、ネットワーク状態の特性、暗黙的または明示的に製剤化することができるトラフィックエンジニアリング問題の解決策を導き出す、そしておそらく制御アクションのセットをインスタンス化の合理的な見積りを要求します。制御動作は、ルーティング、戦術的な能力の獲得を制御、およびトラフィック管理機能を制御に関連するパラメータの操作を含むことができます。
The following list of instruments may be applicable to the solution context of Internet traffic engineering.
楽器の以下のリストは、インターネットトラフィックエンジニアリングのソリューションコンテキストにも適用することができます。
(1) A set of policies, objectives, and requirements (which may be context dependent) for network performance evaluation and performance optimization.
ポリシー、目的、およびネットワークパフォーマンスの評価とパフォーマンスの最適化のために（文脈依存であってもよい）の要件（1）セット。
(2) A collection of online and possibly offline tools and mechanisms for measurement, characterization, modeling, and control of Internet traffic and control over the placement and allocation of network resources, as well as control over the mapping or distribution of traffic onto the infrastructure.
（2）測定、特性評価、モデリング、およびネットワークリソースの配置と割り当てを超えるインターネット・トラフィックと制御の制御のためのオンラインとオフラインの可能性ツールやメカニズムのコレクションだけでなく、インフラへのトラフィックのマッピングや分布を制御します。
(3) A set of constraints on the operating environment, the network protocols, and the traffic engineering system itself.
（3）動作環境、ネットワークプロトコル、およびトラフィックエンジニアリングシステム自体上の制約のセット。
(4) A set of quantitative and qualitative techniques and methodologies for abstracting, formulating, and solving traffic engineering problems.
（4）、抽象化処方、及びトラフィックエンジニアリングの問題を解決するための定量的および定性的な技術および方法論のセット。
(5) A set of administrative control parameters which may be manipulated through a Configuration Management (CM) system. The CM system itself may include a configuration control subsystem, a configuration repository, a configuration accounting subsystem, and a configuration auditing subsystem.
（5）構成管理（CM）システムを介して操作することができる管理制御パラメータのセット。 CMシステム自体は、構成制御サブシステム、構成リポジトリ、構成アカウンティング・サブシステム、および構成監査サブシステムを含むことができます。
(6) A set of guidelines for network performance evaluation, performance optimization, and performance improvement.
（6）Aネットワーク性能評価、パフォーマンスの最適化、および性能向上のためのガイドラインのセット。
Derivation of traffic characteristics through measurement and/or estimation is very useful within the realm of the solution space for traffic engineering. Traffic estimates can be derived from customer subscription information, traffic projections, traffic models, and from actual empirical measurements. The empirical measurements may be performed at the traffic aggregate level or at the flow level in order to derive traffic statistics at various levels of detail. Measurements at the flow level or on small traffic aggregates may be performed at edge nodes, where traffic enters and leaves the network. Measurements at large traffic aggregate levels may be performed within the core of the network where potentially numerous traffic flows may be in transit concurrently.
測定および/または推定を通過するトラフィック特性の導出は、トラフィックエンジニアリングのための解空間の領域内で非常に便利です。トラフィックの見積もりは、顧客のサブスクリプション情報、交通予測、トラフィックモデルから、実際の実験的測定から導出することができます。経験的な測定は、さまざまな詳細レベルでトラフィック統計を導出するために、トラフィック集約レベルまたはフロー・レベルで実行されてもよいです。フローレベルまたは小さなトラフィック凝集体の測定は、トラフィックがネットワークに入り、出るエッジノード、で行うことができます。大きなトラフィック集約レベルでの測定は、潜在的に多数のトラフィックフローを同時に輸送であってもよく、ネットワークのコア内で実行されてもよいです。
To conduct performance studies and to support planning of existing and future networks, a routing analysis may be performed to determine the path(s) the routing protocols will choose for various traffic demands, and to ascertain the utilization of network resources as traffic is routed through the network. The routing analysis should capture the selection of paths through the network, the assignment of traffic across multiple feasible routes, and the multiplexing of IP traffic over traffic trunks (if such constructs exists) and over the underlying network infrastructure. A network topology model is a necessity for routing analysis. A network topology model may be extracted from network architecture documents, from network designs, from information contained in router configuration files, from routing databases, from routing tables, or from automated tools that discover and depict network topology information. Topology information may also be derived from servers that monitor network state, and from servers that perform provisioning functions.
パフォーマンスの研究を行うためには、既存および将来のネットワークの計画をサポートするために、ルーティング分析は、ルーティングプロトコルは、様々な交通需要のために選択すると、トラフィックが経由でルーティングされるように、ネットワークリソースの使用率を確認するために、パス（複数可）を決定するために行うことができますネットワーク。経路分析は、（そのような構築物が存在する場合）は、ネットワークを介して経路を選択する、複数の実現可能な経路を横切るトラフィックの割り当て、及びトラフィックトランク上のIPトラフィックの多重化をキャプチャし、基礎となるネットワークインフラストラクチャ上べきです。ネットワークトポロジモデルは、分析をルーティングする必要があることです。ネットワークトポロジモデルは、ルーティングテーブルから、または発見し、ネットワークトポロジー情報を示している自動化ツールから、ルーティングデータベースから、ルータコンフィギュレーションファイルに含まれている情報から、ネットワーク設計から、ネットワークアーキテクチャの文書から抽出することができます。トポロジ情報は、ネットワークの状態を監視するサーバから、およびプロビジョニング機能を実行するサーバに由来してもよいです。
Routing in operational IP networks can be administratively controlled at various levels of abstraction including the manipulation of BGP attributes and manipulation of IGP metrics. For path oriented technologies such as MPLS, routing can be further controlled by the manipulation of relevant traffic engineering parameters, resource parameters, and administrative policy constraints. Within the context of MPLS, the path of an explicit label switched path (LSP) can be computed and established in various ways including: (1) manually, (2) automatically online using constraint-based routing processes implemented on label switching routers, and (3) automatically offline using constraint-based routing entities implemented on external traffic engineering support systems.
運用IPネットワークにおけるルーティングは、管理IGPメトリックのBGPの操作属性と操作を含む、抽象化の様々なレベルで制御することができます。 MPLSなどの経路指向技術のために、ルーティングはさらに、関連するトラフィックエンジニアリングパラメータ、リソースパラメータ、および管理ポリシー制約の操作によって制御することができます。 MPLSの文脈内で、明示的なラベルの経路が計算を含む様々な方法で確立することができるパス（LSP）を切り替える：（1）手動で、（2）自動的にオンラインラベルスイッチングルータに実装制約ベースのルーティングプロセスを使用して、及び（3）自動的に外部トラフィックエンジニアリング・サポート・システムに実装制約ベースのルーティングエンティティを使用してオフライン。
Minimizing congestion is a significant aspect of Internet traffic engineering. This subsection gives an overview of the general approaches that have been used or proposed to combat congestion problems.
輻輳を最小限に抑えることにより、インターネットトラフィックエンジニアリングの重要な側面です。ここでは、輻輳問題に対処するために使用されるか、または提案されている一般的なアプローチの概要を説明します。
Congestion management policies can be categorized based upon the following criteria (see e.g., [YARE95] for a more detailed taxonomy of congestion control schemes): (1) Response time scale which can be characterized as long, medium, or short; (2) reactive versus preventive which relates to congestion control and congestion avoidance; and (3) supply side versus demand side congestion management schemes. These aspects are discussed in the following paragraphs.
輻輳管理ポリシーがある（例えば、[YARE95】輻輳制御方式のより詳細な分類のために）、以下の基準に基づいて分類することができる：長い、媒体、又は短いとして特徴付けることができる（1）応答時間スケール。 （2）輻輳制御と輻輳回避に関するもの予防に対する反応性;需要側輻輳管理方式対及び（3）供給側。これらの態様は、以下の段落で説明されています。
(1) Congestion Management based on Response Time Scales
応答時間スケールに基づいて、（1）輻輳管理
- Long (weeks to months): Capacity planning works over a relatively long time scale to expand network capacity based on estimates or forecasts of future traffic demand and traffic distribution. Since router and link provisioning take time and are generally expensive, these upgrades are typically carried out in the weeks-to-months or even years time scale.
- ロング（数週間から数ヶ月）：キャパシティプランニングは、将来の交通需要やトラフィック分布の推定値や予測に基づいて、ネットワーク容量を拡張するために、比較的長い時間スケール上で動作します。ルータとリンクのプロビジョニングには時間がかかるし、一般的に高価であるため、これらのアップグレードは通常、数週間、数ヶ月、または数年の時間スケールで行われます。
- Medium (minutes to days): Several control policies fall within the medium time scale category. Examples include: (1) Adjusting IGP and/or BGP parameters to route traffic away or towards certain segments of the network; (2) Setting up and/or adjusting some explicitly routed label switched paths (ER-LSPs) in MPLS networks to route some traffic trunks away from possibly congested resources or towards possibly more favorable routes; (3) re-configuring the logical topology of the network to make it correlate more closely with the spatial traffic distribution using for example some underlying path-oriented technology such as MPLS LSPs, ATM PVCs, or optical channel trails. Many of these adaptive medium time scale response schemes rely on a measurement system that monitors changes in traffic distribution, traffic shifts, and network resource utilization and subsequently provides feedback to the online and/or offline traffic engineering mechanisms and tools which employ this feedback information to trigger certain control actions to occur within the network. The traffic engineering mechanisms and tools can be implemented in a distributed fashion or in a centralized fashion, and may have a hierarchical structure or a flat structure. The comparative merits of distributed and centralized control structures for networks are well known. A centralized scheme may have global visibility into the network state and may produce potentially more optimal solutions. However, centralized schemes are prone to single points of failure and may not scale as well as distributed schemes. Moreover, the information utilized by a centralized scheme may be stale and may not reflect the actual state of the network. It is not an objective of this memo to make a recommendation between distributed and centralized schemes. This is a choice that network administrators must make based on their specific needs.
- ミディアム（日分）：いくつかの制御ポリシーは、メディア時間スケールのカテゴリに分類されます。例としては、（1）離れて又はネットワークの特定のセグメントに向かってトラフィックをルーティングするIGPおよび/またはBGPパラメータを調整します。 （2）の設定および/またはいくつかの明示的にルーティングされたラベルを調整するには、おそらく混雑資源からか、おそらくより有利なルートに向けていくつかのトラフィックトランク離れルートにMPLSネットワークにおけるパス（ER-LSPを）切り替えます。 （3）再構成し、それはそのようなMPLSのLSP、ATM PVCの、または光チャネルトレイルとして、例えば、いくつかの基礎のパス指向技術を用いた空間トラフィック分布とより密接に相関するためにネットワークの論理トポロジを。これらの適応メディア時間スケール応答スキームの多くは、トラフィック分散、トラフィックシフト、およびネットワークリソース使用率の変化を監視測定システムに依存しており、その後に、このフィードバック情報を利用し、オンラインおよび/またはオフライン交通工学メカニズムおよびツールへのフィードバックを提供しますネットワーク内で発生する特定の制御アクションをトリガーします。トラフィックエンジニアリング機構およびツールは、分散方式でまたは集中方式で実現することができ、階層構造またはフラット構造を有していてもよいです。ネットワークのための分散型と集中制御構造の比較の利点はよく知られています。集中方式は、ネットワーク状態にグローバルな可視性を有することができ、潜在的に、より最適なソリューションを生成することができます。しかし、集中方式は単一障害点に傾向があり、分散方式と同様にスケーリングしないことができます。また、集中方式で利用される情報が古くなっていてもよく、ネットワークの実際の状態を反映しないかもしれません。分散と集中のスキーム間の勧告を行うために、このメモの目的ではありません。これは、ネットワーク管理者が特定のニーズに基づいて行わなければならないということな選択肢です。
- Short (picoseconds to minutes): This category includes packet level processing functions and events on the order of several round trip times. It includes router mechanisms such as passive and active buffer management. These mechanisms are used to control congestion and/or signal congestion to end systems so that they can adaptively regulate the rate at which traffic is injected into the network. One of the most popular active queue management schemes, especially for TCP traffic, is Random Early Detection (RED) [FLJA93], which supports congestion avoidance by controlling the average queue size. During congestion (but before the queue is filled), the RED scheme chooses arriving packets to "mark" according to a probabilistic algorithm which takes into account the average queue size. For a router that does not utilize explicit congestion notification (ECN) see e.g., [FLOY94], the marked packets can simply be dropped to signal the inception of congestion to end systems. On the other hand, if the router supports ECN, then it can set the ECN field in the packet header. Several variations of RED have been proposed to support different drop precedence levels in multi-class environments [RFC-
- ショート（分ピコ秒）：このカテゴリには、いくつかの往復時間の順にパケットレベルの処理機能とイベントが含まれます。そのような受動的および能動バッファ管理などのルータ機構を含みます。これらのメカニズムは、それらが適応トラフィックがネットワークに注入される速度を調節することができるようにシステムを終了する輻輳及び/又は信号の輻輳を制御するために使用されます。特にTCPトラフィックのための最も人気のあるアクティブキュー管理方式の一つは、平均キューサイズを制御することにより、輻輳回避をサポートしてランダム早期検出（RED）[FLJA93]、です。輻輳（ただし、キューがいっぱいになる前に）中、RED方式が考慮平均キューサイズをとる確率アルゴリズムに従って「マーク」にパケットを到着選択します。 [FLOY94]、明示的輻輳通知（ECN）は、例えば参照利用していないルータは、マーキングされたパケットは、単にシステムを終了する渋滞の開始を通知するためにドロップすることができます。ルータがECNをサポートしている一方、それは、パケットヘッダ内のECNフィールドを設定することができます。 REDのいくつかのバリエーションが多クラス環境で異なるドロップ優先レベルをサポートするために提案されてきた[RFC-
2597], e.g., RED with In and Out (RIO) and Weighted RED. There is general consensus that RED provides congestion avoidance performance which is not worse than traditional Tail-Drop (TD) queue management (drop arriving packets only when the queue is full). Importantly, however, RED reduces the possibility of global synchronization and improves fairness among different TCP sessions. However, RED by itself can not prevent congestion and unfairness caused by sources unresponsive to RED, e.g., UDP traffic and some misbehaved greedy connections. Other schemes have been proposed to improve the performance and fairness in the presence of unresponsive traffic. Some of these schemes were proposed as theoretical frameworks and are typically not available in existing commercial products. Two such schemes are Longest Queue Drop (LQD) and Dynamic Soft Partitioning with Random Drop (RND) [SLDC98].
2597]、例えば、InおよびアウトとRED（RIO）と重み付けRED。 REDは、（キューがいっぱいになった場合にのみ、到着したパケットをドロップする）伝統的なテールドロップ（TD）キュー管理よりも悪くはない輻輳回避性能を提供し、一般的なコンセンサスがあります。重要なことは、しかし、REDは、グローバル同期の可能性を低減し、異なるTCPセッション間の公平性を向上させます。しかし、それだけでREDはREDに反応しないソースによって引き起こされる渋滞や不公平を防ぐことができない、例えば、UDPトラフィックといくつかは貪欲な接続をmisbehaved。他の方式は、応答しないトラフィックの存在下でのパフォーマンスと公平性を改善するために提案されてきました。これらの方式のうちのいくつかは、理論的な枠組みとして提案し、一般的に、既存の商用製品では利用できませんされました。二つのそのようなスキームはランダムドロップ（RND）[SLDC98]と最長キュードロップ（LQD）とダイナミックソフトパーティショニングされています。
(2) Congestion Management: Reactive versus Preventive Schemes
（2）輻輳管理：予防スキーム対反応
- Reactive: reactive (recovery) congestion management policies react to existing congestion problems to improve it. All the policies described in the long and medium time scales above can be categorized as being reactive especially if the policies are based on monitoring and identifying existing congestion problems, and on the initiation of relevant actions to ease a situation.
- 反応：反応性（回復）輻輳管理ポリシーは、それを改善するために、既存の輻輳問題に反応します。ポリシーは、既存の輻輳問題を監視し、識別に基づいて、状況を容易にするために、関連するアクションの開始にされている場合は、上記のスケール中長期時間で説明されているすべてのポリシーは、特に反応性であるとして分類することができます。
- Preventive: preventive (predictive/avoidance) policies take proactive action to prevent congestion based on estimates and predictions of future potential congestion problems. Some of the policies described in the long and medium time scales fall into this category. They do not necessarily respond immediately to existing congestion problems. Instead forecasts of traffic demand and workload distribution are considered and action may be taken to prevent potential congestion problems in the future. The schemes described in the short time scale (e.g., RED and its variations, ECN, LQD, and RND) are also used for congestion avoidance since dropping or marking packets before queues actually overflow would trigger corresponding TCP sources to slow down.
- 予防：予防（予測/回避）の政策は、将来の潜在的な輻輳問題の見積り及び予測に基づいて輻輳を防ぐために、積極的な行動を取ります。中長期時間スケールで説明したポリシーの一部は、このカテゴリに分類されます。彼らは、必ずしも既存の輻輳問題に即座に応答しません。代わりに、トラフィック需要およびワークロード分布の予測が考慮され、アクションは、将来の潜在的な輻輳の問題を防ぐために取ることができます。短い時間スケール（例えば、REDおよびその変形、ECN、LQD、およびRND）に記載の方式は、実際にオーバーフローが遅くするTCPソースに対応するトリガするキューする前にパケットをドロップまたはマーキングので、輻輳回避のために使用されます。
(3) Congestion Management: Supply Side versus Demand Side Schemes
（3）輻輳管理：サプライサイドデマンドサイドスキーム対
- Supply side: supply side congestion management policies increase the effective capacity available to traffic in order to control or obviate congestion. This can be accomplished by augmenting capacity. Another way to accomplish this is to minimize congestion by having a relatively balanced distribution of traffic over the network. For example, capacity planning should aim to provide a physical topology and associated link bandwidths that match estimated traffic workload and traffic distribution based on forecasting (subject to budgetary and other constraints). However, if actual traffic distribution does not match the topology derived from capacity panning (due to forecasting errors or facility constraints for example), then the traffic can be mapped onto the existing topology using routing control mechanisms, using path oriented technologies (e.g., MPLS LSPs and optical channel trails) to modify the logical topology, or by using some other load redistribution mechanisms.
- サプライサイド：供給側の輻輳管理ポリシーは、輻輳を制御するか、または回避するために、トラフィックに利用できる効果的な容量を増やします。これは、容量を増大させることによって達成することができます。これを達成するもう一つの方法は、ネットワーク上のトラフィックの比較的バランスのとれた分布を持つことで輻輳を最小限に抑えることです。たとえば、容量計画は、物理トポロジーと予測（予算やその他の制約を受ける）に基づいて推定トラフィックの負荷やトラフィック分布に一致する関連するリンクの帯域幅を提供することを目指すべきです。ただし、実際のトラフィック分布（たとえばによる予測エラーまたは設備の制約）パニング能力に由来するトポロジーと一致しない場合、トラフィックは、パス指向技術を使用して、経路制御機構を使用して、既存のトポロジにマッピングすることができる（例えば、MPLS LSPと光チャネルトレイル）論理トポロジを変更し、またはいくつかの他の負荷再分配機構を使用してします。
- Demand side: demand side congestion management policies control or regulate the offered traffic to alleviate congestion problems. For example, some of the short time scale mechanisms described earlier (such as RED and its variations, ECN, LQD, and RND) as well as policing and rate shaping mechanisms attempt to regulate the offered load in various ways. Tariffs may also be applied as a demand side instrument. To date, however, tariffs have not been used as a means of demand side congestion management within the Internet.
- 需要側：需要側の輻輳管理ポリシーを制御または輻輳問題を軽減するために提供されたトラフィックを規制します。例えば、前述した短い時間スケール機構の一部（例えば、REDおよびその変形例としては、ECN、LQD、およびRND）ならびにポリシングおよびレートシェーピングメカニズムは、様々な方法で提供された負荷を調節することを試みます。関税はまた、需要側の機器として適用することができます。しかし、今日まで、関税がインターネット内の需要側の輻輳管理の手段として使用されていませんでした。
In summary, a variety of mechanisms can be used to address congestion problems in IP networks. These mechanisms may operate at multiple time-scales.
要約すると、種々の機構は、IPネットワークにおける輻輳問題に対処するために使用することができます。これらの機構は、複数の時間スケールで動作することができます。
The operational context of Internet traffic engineering is characterized by constant change which occur at multiple levels of abstraction. The implementation context demands effective planning, organization, and execution. The planning aspects may involve determining prior sets of actions to achieve desired objectives. Organizing involves arranging and assigning responsibility to the various components of the traffic engineering system and coordinating the activities to accomplish the desired TE objectives. Execution involves measuring and applying corrective or perfective actions to attain and maintain desired TE goals.
インターネットトラフィックエンジニアリングの運用状況は、抽象化の複数のレベルで発生し、一定の変化によって特徴付けられます。実装のコンテキストでは効果的な計画、組織、および実行を要求しています。計画の側面は、所望の目的を達成するための行動の前にセットを決定することを含むことができます。組織は、配置やトラフィックエンジニアリングシステムの様々な構成要素に責任を割り当て、希望TEの目的を達成するために活動を調整含まれます。実行は、所望のTEの目標を達成し、維持するための是正または完全化措置を測定し、適用することを含みます。
This section describes a generic process model that captures the high level practical aspects of Internet traffic engineering in an operational context. The process model is described as a sequence of actions that a traffic engineer, or more generally a traffic engineering system, must perform to optimize the performance of an operational network (see also [RFC-2702, AWD2]). The process model described here represents the broad activities common to most traffic engineering methodologies although the details regarding how traffic engineering is executed may differ from network to network. This process model may be enacted explicitly or implicitly, by an automaton and/or by a human.
このセクションでは、運用状況のインターネットトラフィックエンジニアリングのハイレベルの実用的な側面を捉え、一般的なプロセスモデルを記述しています。プロセスモデルは、トラフィック・エンジニア、またはより一般的にトラフィックエンジニアリング・システムは、運用ネットワークの性能を最適化するために実行しなければならないアクションのシーケンスとして記述されている（参照[RFC-2702 AWD2]）。トラフィックエンジニアリングを実行する方法に関する詳細は、ネットワークへのネットワークと異なる場合がありますが、ここで説明するプロセスモデルは、ほとんどのトラフィックエンジニアリング手法に共通する幅広い活動を表しています。このプロセスモデルはオートマトンによっておよび/またはヒトによって、明示的または暗示的に制定することができます。
The traffic engineering process model is iterative [AWD2]. The four phases of the process model described below are repeated continually.
トラフィックエンジニアリング・プロセス・モデルは、[AWD2]反復的です。以下で説明するプロセスモデルの4つのフェーズは、継続的に繰り返されます。
The first phase of the TE process model is to define the relevant control policies that govern the operation of the network. These policies may depend upon many factors including the prevailing business model, the network cost structure, the operating constraints, the utility model, and optimization criteria.
TEプロセスモデルの最初の段階は、ネットワークの動作を管理関連する制御ポリシーを定義することです。これらのポリシーは、現行のビジネスモデル、ネットワークのコスト構造、運用上の制約、実用新案、および最適化基準を含む多くの要因に依存し得ます。
The second phase of the process model is a feedback mechanism involving the acquisition of measurement data from the operational network. If empirical data is not readily available from the network, then synthetic workloads may be used instead which reflect either the prevailing or the expected workload of the network. Synthetic workloads may be derived by estimation or extrapolation using prior empirical data. Their derivation may also be obtained using mathematical models of traffic characteristics or other means.
プロセスモデルの第二相は、運用ネットワークからの測定データの取得を含むフィードバック機構です。経験的データは、ネットワークから容易に入手できない場合は、合成ワークロードのいずれか優勢またはネットワークの予想される作業負荷反射する代わりに使用することができます。合成ワークロードは、従来の経験的データを用いて推定または外挿によって誘導することができます。彼らの導出はまた、トラフィックの特性または他の手段の数学的モデルを用いて得ることができます。
The third phase of the process model is to analyze the network state and to characterize traffic workload. Performance analysis may be proactive and/or reactive. Proactive performance analysis identifies potential problems that do not exist, but could manifest in the future. Reactive performance analysis identifies existing problems, determines their cause through diagnosis, and evaluates alternative approaches to remedy the problem, if necessary. A number of quantitative and qualitative techniques may be used in the analysis process, including modeling based analysis and simulation. The analysis phase of the process model may involve investigating the concentration and distribution of traffic across the network or relevant subsets of the network, identifying the characteristics of the offered traffic workload, identifying existing or potential bottlenecks, and identifying network pathologies such as ineffective link placement, single points of failures, etc. Network pathologies may result from many factors including inferior network architecture, inferior network design, and configuration problems. A traffic matrix may be constructed as part of the analysis process. Network analysis may also be descriptive or prescriptive.
プロセスモデルの第3段階は、ネットワークの状態を分析し、トラフィックの負荷を特徴付けることです。パフォーマンス分析は、積極的かつ/または反応性であり得ます。積極的なパフォーマンス分析は存在しませんが、将来的にはマニフェスト可能性のある潜在的な問題を識別します。反応性パフォーマンス分析は、既存の問題を特定し、診断を介して自分の原因を決定し、必要に応じて、問題を解決するための代替的なアプローチを評価します。定量的および定性的な多くの技術は、モデリングに基づく分析とシミュレーションを含む、分析プロセスで使用することができます。プロセスモデルの分析フェーズは、ネットワークまたはネットワークの関連するサブセットにトラフィックの濃度および分布を調べる提供トラフィックワークロードの特性を識別、既存または潜在的なボトルネックを識別し、そのような無効リンクの配置などのネットワーク病理を識別含み得ます、単一障害点などネットワーク病状が劣るネットワークアーキテクチャ、下位ネットワーク設計、及び構成上の問題を含む多くの要因に起因し得ます。トラフィック行列は、分析プロセスの一部として構成してもよいです。ネットワーク分析はまた、記述や規範かもしれません。
The fourth phase of the TE process model is the performance optimization of the network. The performance optimization phase involves a decision process which selects and implements a set of actions from a set of alternatives. Optimization actions may include the use of appropriate techniques to either control the offered traffic or to control the distribution of traffic across the network. Optimization actions may also involve adding additional links or increasing link capacity, deploying additional hardware such as routers and switches, systematically adjusting parameters associated with routing such as IGP metrics and BGP attributes, and adjusting traffic management parameters. Network performance optimization may also involve starting a network planning process to improve the network architecture, network design, network capacity, network technology, and the configuration of network elements to accommodate current and future growth.
TEプロセスモデルの第四段階は、ネットワークのパフォーマンスの最適化です。パフォーマンスの最適化フェーズを選択し、選択肢の集合からのアクションのセットを実装して意思決定プロセスを含みます。最適化のアクションが提供されたトラフィックを制御するか、またはネットワーク上のトラフィックの分布を制御するために、適切な技術の使用を含むことができます。最適化アクションは、追加のリンクを追加したり、リンク容量を増加させる、ルータやスイッチなどの追加のハードウェアを展開する、系統的にそのようなIGPメトリックとしてルーティングおよびBGP属性、およびトラフィック管理パラメータを調整することに関連するパラメータを調整することを含むことができます。ネットワークパフォーマンスの最適化は、現在および将来の成長に対応するために、ネットワークアーキテクチャ、ネットワーク設計、ネットワーク容量、ネットワーク技術、およびネットワーク要素の構成を改善するために、ネットワーク計画プロセスを開始することを含むことができます。
The key components of the traffic engineering process model include a measurement subsystem, a modeling and analysis subsystem, and an optimization subsystem. The following subsections examine these components as they apply to the traffic engineering process model.
トラフィックエンジニアリング・プロセス・モデルの主要コンポーネントは、測定サブシステム、モデリングと解析サブシステム、および最適化のサブシステムが含まれます。彼らはトラフィックエンジニアリングプロセスモデルに適用される以下のサブセクションでは、これらのコンポーネントを調べます。
Measurement is crucial to the traffic engineering function. The operational state of a network can be conclusively determined only through measurement. Measurement is also critical to the optimization function because it provides feedback data which is used by traffic engineering control subsystems. This data is used to adaptively optimize network performance in response to events and stimuli originating within and outside the network. Measurement is also needed to determine the quality of network services and to evaluate the effectiveness of traffic engineering policies. Experience suggests that measurement is most effective when acquired and applied systematically.
測定は、トラフィックエンジニアリング機能に不可欠です。ネットワークの動作状態は、決定的にのみ測定を介して決定することができます。それは、トラフィックエンジニアリング制御サブシステムによって使用されているフィードバックデータを提供するため、測定はまた、最適化機能に重要です。このデータは、適応的イベントとネットワーク内及び外発信刺激に応答して、ネットワークパフォーマンスを最適化するために使用されます。測定は、ネットワークサービスの品質を決定するために、トラフィックエンジニアリングポリシーの有効性を評価するために必要とされます。経験を取得し、体系的に適用したときの測定が最も効果的であることを示唆しています。
When developing a measurement system to support the traffic engineering function in IP networks, the following questions should be carefully considered: Why is measurement needed in this particular context? What parameters are to be measured? How should the measurement be accomplished? Where should the measurement be performed? When should the measurement be performed? How frequently should the monitored variables be measured? What level of measurement accuracy and reliability is desirable? What level of measurement accuracy and reliability is realistically attainable? To what extent can the measurement system permissibly interfere with the monitored network components and variables? What is the acceptable cost of measurement? The answers to these questions will determine the measurement tools and methodologies appropriate in any given traffic engineering context.
IPネットワークにおけるトラフィックエンジニアリング機能をサポートするための測定システムを開発する場合、以下の質問を慎重に考慮する必要があります：測定は、この特定の状況で必要とされるのはなぜ？どのようなパラメータを測定されるべきですか？測定はどのように達成すべきですか？どこで測定が行われるべき？ときに測定が行われるべき？どのくらいの頻度で監視対象の変数が測定されなければなりませんか？測定精度と信頼性のどのようなレベルであることが望ましいですか？測定精度と信頼性のレベルは、現実的に達成可能でしょうか？どの程度まで測定システムは、許容監視対象のネットワークコンポーネントと変数を妨げることができますか？測定の許容コストとは何ですか？これらの質問に対する答えは、任意のトラフィックエンジニアリングの文脈における適切な測定ツールと方法論を決定します。
It should also be noted that there is a distinction between measurement and evaluation. Measurement provides raw data concerning state parameters and variables of monitored network elements. Evaluation utilizes the raw data to make inferences regarding the monitored system.
また、測定および評価の間に区別があることに留意すべきです。測定は、状態パラメータおよび監視ネットワーク要素の変数に関する生データを提供します。評価は、監視対象システムに関する推論を行うために、生のデータを利用しています。
Measurement in support of the TE function can occur at different levels of abstraction. For example, measurement can be used to derive packet level characteristics, flow level characteristics, user or customer level characteristics, traffic aggregate characteristics, component level characteristics, and network wide characteristics.
TE機能のサポートにおける測定は、抽象化の異なるレベルで発生する可能性があります。例えば、測定は、パケットレベル特性、フローレベル特性、ユーザまたは顧客レベル特性、トラフィック集合特性、コンポーネントレベルの特性、およびネットワーク全体の特性を導出するために使用することができます。
Modeling and analysis are important aspects of Internet traffic engineering. Modeling involves constructing an abstract or physical representation which depicts relevant traffic characteristics and network attributes.
モデリングと解析は、インターネットトラフィックエンジニアリングの重要な側面です。モデルは、関連するトラフィックの特性およびネットワーク属性を描く抽象的または物理的な表現を構築する必要。
A network model is an abstract representation of the network which captures relevant network features, attributes, and characteristics, such as link and nodal attributes and constraints. A network model may facilitate analysis and/or simulation which can be used to predict network performance under various conditions as well as to guide network expansion plans.
ネットワークモデルは、関連するネットワーク機能、属性、およびそのようなリンクやリンパ節の属性や制約などの特性を、キャプチャするネットワークの抽象的表現です。ネットワークモデルは、分析及び/又は様々な条件下でネットワーク性能を予測するだけでなく、ネットワークの拡張計画を導くために使用することができるシミュレーションを容易にすることができます。
In general, Internet traffic engineering models can be classified as either structural or behavioral. Structural models focus on the organization of the network and its components. Behavioral models focus on the dynamics of the network and the traffic workload. Modeling for Internet traffic engineering may also be formal or informal.
一般的には、インターネットトラフィックエンジニアリングモデルは、構造的または行動のいずれかに分類することができます。構造モデルは、ネットワークの組織とその構成要素に焦点を当てます。行動モデルは、ネットワークとトラフィックの負荷のダイナミクスに焦点を当てます。インターネットトラフィックエンジニアリングのためのモデリングはまた、公式または非公式のかもしれません。
Accurate behavioral models for traffic sources are particularly useful for analysis. Development of behavioral traffic source models that are consistent with empirical data obtained from operational networks is a major research topic in Internet traffic engineering. These source models should also be tractable and amenable to analysis. The topic of source models for IP traffic is a research topic and is therefore outside the scope of this document. Its importance, however, must be emphasized.
トラフィックソースの正確な動作モデルは、分析のために特に有用です。運用ネットワークから取得した実験データと一致している行動のトラフィックソースモデルの開発は、インターネットトラフィックエンジニアリングにおける主要な研究テーマです。これらのソースモデルは、分析に扱いやすいと従順でなければなりません。 IPトラフィックの送信元モデルのトピックは、研究課題であり、この文書の範囲外のことです。その重要性は、しかし、強調しなければなりません。
Network simulation tools are extremely useful for traffic engineering. Because of the complexity of realistic quantitative analysis of network behavior, certain aspects of network performance studies can only be conducted effectively using simulation. A good network simulator can be used to mimic and visualize network characteristics under various conditions in a safe and non-disruptive manner. For example, a network simulator may be used to depict congested resources and hot spots, and to provide hints regarding possible solutions to network performance problems. A good simulator may also be used to validate the effectiveness of planned solutions to network issues without the need to tamper with the operational network, or to commence an expensive network upgrade which may not achieve the desired objectives. Furthermore, during the process of network planning, a network simulator may reveal pathologies such as single points of failure which may require additional redundancy, and potential bottlenecks and hot spots which may require additional capacity.
ネットワークシミュレーションツールは、トラフィックエンジニアリングのために非常に有用です。そのためネットワークの動作の現実的な定量分析が複雑で、ネットワークパフォーマンスの研究の特定の側面にのみ効果的にシミュレーションを用いて行うことができます。良好なネットワークシミュレータは、安全かつ非破壊的方法で種々の条件下でネットワーク特性を模倣し、可視化するために使用することができます。たとえば、ネットワークシミュレータは混雑資源やホットスポットを描くために使用することができ、パフォーマンスの問題をネットワーク化するために可能な解決策についてのヒントを提供します。良いシミュレータはまた、運用ネットワークを改ざんすることなく、ネットワーク上の問題への計画ソリューションの有効性を検証するために用いてもよいし、所望の目的を達成できないことがあり、高価なネットワークのアップグレードを開始します。さらに、ネットワーク計画の処理中に、ネットワークシミュレータは、このような付加的な冗長性を必要とするかもしれない単一障害点、および追加の容量を必要とするかもしれない潜在的なボトルネックとホットスポットのような病状を明らかにすることができます。
Routing simulators are especially useful in large networks. A routing simulator may identify planned links which may not actually be used to route traffic by the existing routing protocols. Simulators can also be used to conduct scenario based and perturbation based analysis, as well as sensitivity studies. Simulation results can be used to initiate appropriate actions in various ways. For example, an important application of network simulation tools is to investigate and identify how best to make the network evolve and grow, in order to accommodate projected future demands.
ルーティングシミュレータは、大規模なネットワークにおいて特に有用です。ルーティング・シミュレータは、実際には既存のルーティングプロトコルでトラフィックをルーティングするために使用されないことが予定リンクを識別することができます。シミュレータはまた、シナリオベースと摂動ベースの分析、ならびに感度試験を行うために使用することができます。シミュレーション結果は、さまざまな方法で適切なアクションを開始するために使用することができます。たとえば、ネットワークシミュレーションツールの重要な用途は、調査し、予測される将来の需要に対応するために、最適なネットワーク進化を作成し、成長する方法を特定することです。
Network performance optimization involves resolving network issues by transforming such issues into concepts that enable a solution, identification of a solution, and implementation of the solution. Network performance optimization can be corrective or perfective. In corrective optimization, the goal is to remedy a problem that has occurred or that is incipient. In perfective optimization, the goal is to improve network performance even when explicit problems do not exist and are not anticipated.
ネットワークパフォーマンスの最適化は、溶液、溶液の同定、およびソリューションの実装を可能にする概念に、このような問題を形質転換することによって、ネットワークの問題を解決することを含みます。ネットワークパフォーマンスの最適化は、修正または完全化することができます。是正の最適化では、目標は、発生した問題を改善することであるか、それは初期です。完全化の最適化では、目標は明示的な問題が存在しないと予想されていない場合でも、ネットワークのパフォーマンスを改善することです。
Network performance optimization is a continual process, as noted previously. Performance optimization iterations may consist of real-time optimization sub-processes and non-real-time network planning sub-processes. The difference between real-time optimization and network planning is primarily in the relative time-scale in which they operate and in the granularity of actions. One of the objectives of a real-time optimization sub-process is to control the mapping and distribution of traffic over the existing network infrastructure to avoid and/or relieve congestion, to assure satisfactory service delivery, and to optimize resource utilization. Real-time optimization is needed because random incidents such as fiber cuts or shifts in traffic demand will occur irrespective of how well a network is designed. These incidents can cause congestion and other problems to manifest in an operational network. Real-time optimization must solve such problems in small to medium time-scales ranging from micro-seconds to minutes or hours. Examples of real-time optimization include queue management, IGP/BGP metric tuning, and using technologies such as MPLS explicit LSPs to change the paths of some traffic trunks [XIAO].
前述のように、ネットワークのパフォーマンスの最適化は、継続的なプロセスです。パフォーマンスの最適化の繰り返しは、リアルタイムの最適化サブプロセスと非リアルタイムネットワーク計画のサブプロセスから構成されてもよいです。リアルタイムの最適化とネットワークの計画との違いは、主に彼らが動作する相対的な時間スケールで、行動の粒度です。リアルタイム最適化サブプロセスの目的の一つは避けおよび/または十分なサービスの提供を確保するために、混雑を緩和し、リソース使用率を最適化するためにマッピングし、既存のネットワークインフラストラクチャ上のトラフィックの分布を制御することです。そのようなトラフィック需要の繊維カットやシフトなど、ランダムな事件は関係なく、ネットワークが設計されてどれだけの発生しますので、リアルタイムでの最適化が必要とされています。これらの事件は、運用ネットワークをでマニフェストに渋滞やその他の問題を引き起こす可能性があります。リアルタイムの最適化は、マイクロ秒から数分または数時間に及ぶ中、時間スケールに小型で、このような問題を解決しなければなりません。リアルタイム最適化の例としては、キュー管理、IGP / BGPメトリックチューニング、および一部のトラフィックトランクのパスを変更するには、このようなMPLS LSPの明示などの技術を使用して、[XIAO]が含まれます。
One of the functions of the network planning sub-process is to initiate actions to systematically evolve the architecture, technology, topology, and capacity of a network. When a problem exists in the network, real-time optimization should provide an immediate remedy. Because a prompt response is necessary, the real-time solution may not be the best possible solution. Network planning may subsequently be needed to refine the solution and improve the situation. Network planning is also required to expand the network to support traffic growth and changes in traffic distribution over time. As previously noted, a change in the topology and/or capacity of the network may be the outcome of network planning.
ネットワーク計画サブプロセスの機能の一つは、体系的なアーキテクチャ、技術、トポロジ、およびネットワークの能力を進化させるアクションを開始することです。問題がネットワークに存在する場合、リアルタイムの最適化は、即時の救済を提供する必要があります。迅速な対応が必要であるため、リアルタイムのソリューションは、可能な限り最良の解決策ではないかもしれません。ネットワーク計画は、その後、ソリューションを洗練して、状況を改善するために必要とされ得ます。ネットワーク計画にも時間をかけて、トラフィックの増加とトラフィック分布の変化をサポートするためにネットワークを拡大するために必要とされます。先に述べたように、ネットワークのトポロジー及び/又は容量の変化は、ネットワークプランニングの結果であってもよいです。
Clearly, network planning and real-time performance optimization are mutually complementary activities. A well-planned and designed network makes real-time optimization easier, while a systematic approach to real-time network performance optimization allows network planning to focus on long term issues rather than tactical considerations. Systematic real-time network performance optimization also provides valuable inputs and insights toward network planning.
明らかに、ネットワーク計画とリアルタイムのパフォーマンスの最適化は、相互補完的な活動です。リアルタイムのネットワーク・パフォーマンスの最適化への体系的なアプローチは、ネットワーク計画は、長期的な問題ではなく、戦術的な考慮事項に集中することができますしながら、十分に計画および設計されたネットワークは、リアルタイムでの最適化が容易になります。体系的リアルタイムネットワークパフォーマンスの最適化はまた、ネットワーク計画に向けた貴重な入力と洞察を提供しています。
Stability is an important consideration in real-time network performance optimization. This aspect will be repeatedly addressed throughout this memo.
安定性は、リアルタイムのネットワーク・パフォーマンスの最適化における重要な考慮事項です。この局面は、繰り返しこのメモ全体で対処されることになります。
This section briefly reviews different traffic engineering approaches proposed and implemented in telecommunications and computer networks. The discussion is not intended to be comprehensive. It is primarily intended to illuminate pre-existing perspectives and prior art concerning traffic engineering in the Internet and in legacy telecommunications networks.
このセクションでは、簡単に提案し、電気通信およびコンピュータネットワークに実装され、異なるトラフィック・エンジニアリング・アプローチを検討します。議論は包括的であることを意図していません。主に、インターネットにし、従来の通信ネットワークにおけるトラフィックエンジニアリングに関する既存の視点や先行技術を照明することを意図しています。
This subsection presents a brief overview of traffic engineering in telephone networks which often relates to the way user traffic is steered from an originating node to the terminating node. This subsection presents a brief overview of this topic. A detailed description of the various routing strategies applied in telephone networks is included in the book by G. Ash [ASH2].
このサブセクションでは、多くの場合、ユーザトラフィックが終端ノードへの発信ノードから操舵される方法に関連する電話ネットワークにおけるトラフィックエンジニアリングの概要を説明します。ここでは、このトピックの概要を示します。電話網で適用さまざまなルーティング戦略の詳細な説明はG.アッシュ[ASH2]によってブックに含まれています。
The early telephone network relied on static hierarchical routing, whereby routing patterns remained fixed independent of the state of the network or time of day. The hierarchy was intended to accommodate overflow traffic, improve network reliability via alternate routes, and prevent call looping by employing strict hierarchical rules. The network was typically over-provisioned since a given fixed route had to be dimensioned so that it could carry user traffic during a busy hour of any busy day. Hierarchical routing in the telephony network was found to be too rigid upon the advent of digital switches and stored program control which were able to manage more complicated traffic engineering rules.
ルーティングパターンがネットワークまたは時刻の状態に固定された独立のままであったことにより、初期電話ネットワークは、静的階層ルーティングに依存していました。階層は、オーバーフロー・トラフィックを収容する代替ルートを介してネットワークの信頼性を向上させ、厳格な階層的な規則を採用することにより、コールループを防止することを意図しました。それはどんな忙しい一日の忙しい時間の間、ユーザトラフィックを運ぶことができるように与えられた固定ルートが寸法なければならなかったので、ネットワークは、通常、オーバープロビジョニングされました。電話ネットワークにおける階層ルーティングはより複雑なトラフィックエンジニアリング規則を管理することができたデジタルスイッチと格納されたプログラム制御の出現時にあまりに剛性であることが見出されました。
Dynamic routing was introduced to alleviate the routing inflexibility in the static hierarchical routing so that the network would operate more efficiently. This resulted in significant economic gains [HUSS87]. Dynamic routing typically reduces the overall loss probability by 10 to 20 percent (compared to static hierarchical routing). Dynamic routing can also improve network resilience by recalculating routes on a per-call basis and periodically updating routes.
ダイナミックルーティングは、ネットワークをより効率的に動作するように、静的な階層型ルーティングにおけるルーティングの柔軟性のを軽減するために導入されました。これは重要な経済的利益[HUSS87]になりました。動的ルーティングは、典型的には、（静的階層ルーティングと比較して）10から20パーセントによって全体的な損失確率を減少させます。動的ルーティングはまた、コールごとにルートを再計算し、定期的にルートを更新することにより、ネットワークの回復力を向上させることができます。
There are three main types of dynamic routing in the telephone network. They are time-dependent routing, state-dependent routing (SDR), and event dependent routing (EDR).
電話ネットワークにおける動的ルーティングの3つの主要な種類があります。それらは時間依存型ルーティング、状態依存型ルーティング（SDR）、およびイベント依存ルーティング（EDR）。
In time-dependent routing, regular variations in traffic loads (such as time of day or day of week) are exploited in pre-planned routing tables. In state-dependent routing, routing tables are updated online according to the current state of the network (e.g., traffic demand, utilization, etc.). In event dependent routing, routing changes are incepted by events (such as call setups encountering congested or blocked links) whereupon new paths are searched out using learning models. EDR methods are real-time adaptive, but they do not require global state information as does SDR. Examples of EDR schemes include the dynamic alternate routing (DAR) from BT, the state-and-time dependent routing (STR) from NTT, and the success-to-the-top (STT) routing from AT&T.
時間依存型ルーティングでは、（例えば、曜日や時間帯など）のトラフィック負荷の定期的な変動は、予め計画ルーティングテーブルに利用されます。状態依存型ルーティングでは、ルーティングテーブルは、ネットワークの現在の状態（例えば、トラフィック需要、使用、等）に応じてオンラインで更新されます。イベント依存ルーティングでは、ルーティングの変更は、新しいパスが学習モデルを使用して検索され、そこで（例えば混雑やブロックされたリンクに遭遇したコール・セットアップなど）のイベントによってinceptedされています。 EDR方法は、リアルタイムの適応ですが、SDRがそうであるように、彼らはグローバルな状態情報を必要としません。 EDRスキームの例は、動的代替ルーティングBT、NTTからの状態および時間依存ルーティング（STR）から（DAR）、及び成功・ツー・トップAT＆Tからルーティング（STT）が挙げられます。
Dynamic non-hierarchical routing (DNHR) is an example of dynamic routing that was introduced in the AT&T toll network in the 1980's to respond to time-dependent information such as regular load variations as a function of time. Time-dependent information in terms of load may be divided into three time scales: hourly, weekly, and yearly. Correspondingly, three algorithms are defined to pre-plan the routing tables. The network design algorithm operates over a year-long interval while the demand servicing algorithm operates on a weekly basis to fine tune link sizes and routing tables to correct forecast errors on the yearly basis. At the smallest time scale, the routing algorithm is used to make limited adjustments based on daily traffic variations. Network design and demand servicing are computed using offline calculations. Typically, the calculations require extensive searches on possible routes. On the other hand, routing may need online calculations to handle crankback. DNHR adopts a "two-link" approach whereby a path can consist of two links at most. The routing algorithm presents an ordered list of route choices between an originating switch and a terminating switch. If a call overflows, a via switch (a tandem exchange between the originating switch and the terminating switch) would send a crankback signal to the originating switch. This switch would then select the next route, and so on, until there are no alternative routes available in which the call is blocked.
動的非階層ルーティング（DNHR）は、時間の関数としての正規負荷変動のような時間依存情報に応答するために1980年代にAT＆T市外ネットワークに導入された動的ルーティングの一例です。時間ごと、週ごと、および年間：負荷の点では時間依存情報は、3つの時間スケールに分けることができます。これに対応して、3つのアルゴリズムは、ルーティングテーブルを事前に計画することが規定されています。オンデマンドサービスアルゴリズムは年単位で予測誤差を補正するために微調整リンクのサイズとルーティングテーブルに週単位で動作しながら、ネットワークの設計アルゴリズムは、一年間の間隔で動作します。最小の時間スケールで、ルーティングアルゴリズムは、毎日のトラフィックの変動に基づいて、限られた調整を行うために使用されます。ネットワーク設計と需要のサービスは、オフライン計算を用いて計算されます。典型的には、計算は、可能なルート上の広範囲の検索を必要とします。一方、ルーティングは、クランクバックを処理するために、オンラインでの計算が必要な場合があります。パスは最大で二つのリンクから構成できるDNHR「は、2つのリンク」のアプローチを採用しています。ルーティングアルゴリズムは、発信スイッチと終端スイッチ間のルートの選択肢の順序付きリストを提示します。コール・オーバーフローは、スイッチ（発信スイッチと終端スイッチとの間のタンデム交換）を介して、発信スイッチにクランクバック信号を送信した場合。コールがブロックされている利用可能な代替ルートが存在しなくなるまで、このスイッチは、その次のルートを選択して、でしょう。
This subsection reviews related prior work that was intended to improve the performance of data networks. Indeed, optimization of the performance of data networks started in the early days of the ARPANET. Other early commercial networks such as SNA also recognized the importance of performance optimization and service differentiation.
このサブセクションのレビューは、データネットワークのパフォーマンスを改善することを意図していた前の仕事に関連します。確かに、データネットワークのパフォーマンスの最適化は、ARPANETの初期の頃に始まりました。このようSNAなどの他の早期の商用ネットワークは、パフォーマンスの最適化とサービスの差別化の重要性を認識しました。
In terms of traffic management, the Internet has been a best effort service environment until recently. In particular, very limited traffic management capabilities existed in IP networks to provide differentiated queue management and scheduling services to packets belonging to different classes.
トラフィック管理の面では、インターネットは、最近までのベストエフォート型サービスの環境となっています。具体的には、非常に限られたトラフィック管理機能は、異なるクラスに属するパケットに差別キュー管理とスケジューリングサービスを提供するために、IPネットワークに存在していました。
In terms of routing control, the Internet has employed distributed protocols for intra-domain routing. These protocols are highly scalable and resilient. However, they are based on simple algorithms for path selection which have very limited functionality to allow flexible control of the path selection process.
ルーティング制御の観点から、インターネットは、ドメイン内ルーティングのための分散プロトコルを採用しています。これらのプロトコルは、高度にスケーラブルで弾力性があります。しかし、それらは経路選択プロセスの柔軟な制御を可能にするために非常に限られた機能性を有するパスを選択するための単純なアルゴリズムに基づいています。
In the following subsections, the evolution of practical traffic engineering mechanisms in IP networks and its predecessors are reviewed.
以下のサブセクションでは、実用的なトラフィックエンジニアリングIPネットワークにおけるメカニズムとその前任者の進化を検討しています。
The early ARPANET recognized the importance of adaptive routing where routing decisions were based on the current state of the network [MCQ80]. Early minimum delay routing approaches forwarded each packet to its destination along a path for which the total estimated transit time was the smallest. Each node maintained a table of network delays, representing the estimated delay that a packet would experience along a given path toward its destination. The minimum delay table was periodically transmitted by a node to its neighbors. The shortest path, in terms of hop count, was also propagated to give the connectivity information.
初期のARPANETは、ルーティング決定はネットワーク[MCQ80]の現在の状態に基づいた適応ルーティングの重要性を認識しました。初期の最小遅延経路は、推定総走行時間が最小であったために経路に沿ってその宛先に各パケットを転送近づきます。各ノードは、パケットがその宛先に向かって所定の経路に沿って経験する推定遅延を表す、ネットワーク遅延のテーブルを維持します。最小遅延テーブルは、定期的に近隣のノードによって送信されました。最短経路は、ホップ数の面でも、接続情報を提供するために増殖させました。
One drawback to this approach is that dynamic link metrics tend to create "traffic magnets" causing congestion to be shifted from one location of a network to another location, resulting in oscillation and network instability.
このアプローチの一つの欠点は、ダイナミック・リンク・メトリックは輻輳が振動し、ネットワークが不安定になり、別の場所にネットワークのある場所からシフトさせる「トラフィック磁石」を作成する傾向があることです。
The Internet evolved from the APARNET and adopted dynamic routing algorithms with distributed control to determine the paths that packets should take en-route to their destinations. The routing algorithms are adaptations of shortest path algorithms where costs are based on link metrics. The link metric can be based on static or dynamic quantities. The link metric based on static quantities may be assigned administratively according to local criteria. The link metric based on dynamic quantities may be a function of a network congestion measure such as delay or packet loss.
インターネットはAPARNETから進化したパケットがその宛先に専用ルートを取るべきパスを決定するために、分散制御によるダイナミックルーティングアルゴリズムを採用しました。ルーティングアルゴリズムは、コストがリンク・メトリックに基づいて、最短パスアルゴリズムの適応です。リンクメトリックは、静的または動的な量に基づくことができます。静的量に基づいてリンクメトリックは、管理上のローカルの基準に従って割り当てることができます。動的量に基づいてリンクメトリックは、遅延やパケットロスなどのネットワーク輻輳測度の関数であってもよいです。
It was apparent early that static link metric assignment was inadequate because it can easily lead to unfavorable scenarios in which some links become congested while others remain lightly loaded. One of the many reasons for the inadequacy of static link metrics is that link metric assignment was often done without considering the traffic matrix in the network. Also, the routing protocols did not take traffic attributes and capacity constraints into account when making routing decisions. This results in traffic concentration being localized in subsets of the network infrastructure and potentially causing congestion. Even if link metrics are assigned in accordance with the traffic matrix, unbalanced loads in the network can still occur due to a number factors including:
それは簡単に他の人が軽くロードされたままで、いくつかのリンクが混雑になっている不利な状況につながる可能性があるため、静的リンクメトリック割当が不十分であったことを早期に明らかでした。静的リンクメトリックの不備のために多くの理由の一つは、リンクメトリック割当は、多くの場合、ネットワーク内のトラフィックマトリクスを考慮せずに行われたということです。ルーティングの決定をする際にも、ルーティングプロトコルは、アカウントにトラフィック属性と容量の制約を取ることはありませんでした。トラフィック濃度におけるこの結果は、ネットワークインフラストラクチャのサブセットに局在し、潜在的に輻輳を引き起こしています。リンクメトリックは、トラフィック行列に応じて割り当てられている場合でも、ネットワーク内の不平衡負荷が依然として起因含む多数の要因によって発生する可能性があります。
- Resources may not be deployed in the most optimal locations from a routing perspective.
- リソースは、ルーティングの観点から、最適な場所に展開することはできません。
- Forecasting errors in traffic volume and/or traffic distribution.
- トラフィック量および/またはトラフィック分布の予測エラー。
- Dynamics in traffic matrix due to the temporal nature of traffic patterns, BGP policy change from peers, etc.
- トラフィックパターンの時間的な性質、ピアからBGPポリシーの変更、等へのトラフィック行列におけるダイナミクス
The inadequacy of the legacy Internet interior gateway routing system is one of the factors motivating the interest in path oriented technology with explicit routing and constraint-based routing capability such as MPLS.
従来のインターネット内部ゲートウェイルーティングシステムの不備は、MPLSなどの明示的ルーティングおよび制約ベースのルーティング機能を持つ経路に関心指向技術を動機要因の一つです。
Type-of-Service (ToS) routing involves different routes going to the same destination with selection dependent upon the ToS field of an IP packet [RFC-2474]. The ToS classes may be classified as low delay and high throughput. Each link is associated with multiple link costs and each link cost is used to compute routes for a particular ToS. A separate shortest path tree is computed for each ToS. The shortest path algorithm must be run for each ToS resulting in very expensive computation. Classical ToS-based routing is now outdated as the IP header field has been replaced by a Diffserv field. Effective traffic engineering is difficult to perform in classical ToS-based routing because each class still relies exclusively on shortest path routing which results in localization of traffic concentration within the network.
タイプオブサービス（TOS）ルーティングは、IPパケットのToSフィールド[RFC-2474]に依存して選択して同じ宛先に向かう異なる経路を含みます。 ToSのクラスは、低遅延かつ高スループットのように分類することができます。各リンクは、複数のリンクコストに関連付けられ、各リンクのコストは、特定のToSのルートを計算するために使用されます。別最短経路ツリーは、各ToSのために計算されます。最短経路アルゴリズムは、非常に高価な計算結果として各ToSのために実行する必要があります。古典のToSベースのルーティングは、IPヘッダフィールドは、DiffServフィールドにより置換されているように、今時代遅れです。各クラスは、依然としてネットワーク内のトラフィックの濃度の局在化をもたらす最短経路ルーティングだけに依存しているので、効果的なトラフィックエンジニアリングは、古典のToSベースのルーティングに行うことは困難です。
Equal Cost Multi-Path (ECMP) is another technique that attempts to address the deficiency in the Shortest Path First (SPF) interior gateway routing systems [RFC-2328]. In the classical SPF algorithm, if two or more shortest paths exist to a given destination, the algorithm will choose one of them. The algorithm is modified slightly in ECMP so that if two or more equal cost shortest paths exist between two nodes, the traffic between the nodes is distributed among the multiple equal-cost paths. Traffic distribution across the equal-cost paths is usually performed in one of two ways: (1) packet-based in a round-robin fashion, or (2) flow-based using hashing on source and destination IP addresses and possibly other fields of the IP header. The first approach can easily cause out-of-order packets while the second approach is dependent upon the number and distribution of flows. Flow-based load sharing may be unpredictable in an enterprise network where the number of flows is relatively small and less heterogeneous (for example, hashing may not be uniform), but it is generally effective in core public networks where the number of flows is large and heterogeneous.
等価コストマルチパス（ECMP）は、最短パス優先（SPF）内部ゲートウェイルーティングシステム[RFC-2328]の欠乏に対処しようとする別の技術です。二つ以上の最短パスが指定された宛先に存在する場合、古典的なSPFアルゴリズムで、アルゴリズムは、それらのいずれかを選択します。二つ以上の等コスト最短経路は、2つのノード間に存在する場合、ノード間のトラフィックは、複数の等コストパスの間で分散されるように、アルゴリズムは、ECMPでわずかに変更されます。等コストパス間でトラフィック分布は、通常、2つの方法のいずれかで行われる：（1）パケットベースのラウンドロビン方式で、または（2）フローベースのソースおよび宛先IPアドレスとのおそらく他のフィールドにハッシュを使用してIPヘッダー。第二のアプローチは、フローの数及び分布に依存しながら、第1のアプローチは、容易にアウトオブオーダーパケット引き起こし得ます。フローベースの負荷分散は、フローの数は、（例えば、ハッシングが均一でなくてもよい）は比較的小さく、少ない不均一であるが、それは一般的にフローの数が大きいコア公衆ネットワーク上で有効である企業ネットワーク内に予測不能であってもよいですそして異質。
In ECMP, link costs are static and bandwidth constraints are not considered, so ECMP attempts to distribute the traffic as equally as possible among the equal-cost paths independent of the congestion status of each path. As a result, given two equal-cost paths, it is possible that one of the paths will be more congested than the other. Another drawback of ECMP is that load sharing cannot be achieved on multiple paths which have non-identical costs.
ECMPにおいては、リンクコストは静的であり、ECMPは、各経路の混雑状況の独立等コストパスの間でできるだけ均等トラフィックを配信しようとするので、帯域幅の制約が考慮されません。結果として、2つの等コスト・パスが与えられると、パスの一方が他方よりも混雑になることが可能です。 ECMPの別の欠点は、ロードシェアリングは、非同一コストを持つ複数のパスで達成することができないということです。
Nimrod is a routing system developed to provide heterogeneous service specific routing in the Internet, while taking multiple constraints into account [RFC-1992]. Essentially, Nimrod is a link state routing protocol which supports path oriented packet forwarding. It uses the concept of maps to represent network connectivity and services at multiple levels of abstraction. Mechanisms are provided to allow restriction of the distribution of routing information.
ニムロデのアカウントに複数の制約をしながら、インターネットで異種のサービス固有のルーティングを提供するために開発されたルーティングシステム[RFC-1992]です。本質的に、ニムロデは、パス指向パケット転送をサポートするリンクステートルーティングプロトコルです。これは、抽象化の複数のレベルでネットワーク接続およびサービスを表すためにマップの概念を使用しています。メカニズムは、ルーティング情報の配信の制限を可能にするために設けられています。
Even though Nimrod did not enjoy deployment in the public Internet, a number of key concepts incorporated into the Nimrod architecture, such as explicit routing which allows selection of paths at originating nodes, are beginning to find applications in some recent constraint-based routing initiatives.
ニムロッドは、公共のインターネットでの展開を楽しむことはなかったにもかかわらず、そのようなノードを起点にパスを選択することができます明示的なルーティングなどのニムロッドアーキテクチャに組み込まれた重要な概念の数は、いくつかの最近の制約ベースのルーティングの取り組みでアプリケーションを見つけるために始めています。
In the overlay model, a virtual-circuit network, such as ATM, frame relay, or WDM, provides virtual-circuit connectivity between routers that are located at the edges of a virtual-circuit cloud. In this mode, two routers that are connected through a virtual circuit see a direct adjacency between themselves independent of the physical route taken by the virtual circuit through the ATM, frame relay, or WDM network. Thus, the overlay model essentially decouples the logical topology that routers see from the physical topology that the ATM, frame relay, or WDM network manages. The overlay model based on ATM or frame relay enables a network administrator or an automaton to employ traffic engineering concepts to perform path optimization by re-configuring or rearranging the virtual circuits so that a virtual circuit on a congested or sub-optimal physical link can be re-routed to a less congested or more optimal one. In the overlay model, traffic engineering is also employed to establish relationships between the traffic management parameters (e.g., PCR, SCR, and MBS for ATM) of the virtual-circuit technology and the actual traffic that traverses each circuit. These relationships can be established based upon known or projected traffic profiles, and some other factors.
オーバーレイモデルでは、このようなATM、フレームリレー、またはWDMとして仮想回路網は、仮想回線雲の縁に位置しているルータ間の仮想回線接続を提供します。このモードでは、仮想回線を介して接続された2つのルータは、物理ATMを介して仮想回路によって取り込ま経路、フレームリレー、またはWDMネットワークの独立自体との間の直接的な隣接を参照します。したがって、オーバーレイ・モデルは、本質的に、ルータはATM、フレームリレー、またはWDMネットワークが管理する物理トポロジから見る論理トポロジを切り離します。 ATMやフレームリレーに基づいてオーバーレイ・モデルは、輻輳又は次善の物理リンク上の仮想回線ができるように再構成または再配置仮想回線によって経路最適化を実行するためにトラフィックエンジニアリングの概念を採用するために、ネットワーク管理者またはオートマトンを可能それほど混雑またはより最適なものに再ルーティング。オーバーレイモデルでは、トラフィックエンジニアリングは、仮想回路技術及び各回路を通過する実際のトラフィックのトラフィック管理パラメータ（例えば、PCR、SCR、およびATMのためのMBS）との間の関係を確立するために使用されます。これらの関係は、既知もしくは予測トラフィックプロファイル、および他のいくつかの要因に基づいて確立することができます。
The overlay model using IP over ATM requires the management of two separate networks with different technologies (IP and ATM) resulting in increased operational complexity and cost. In the fully-meshed overlay model, each router would peer to every other router in the network, so that the total number of adjacencies is a quadratic function of the number of routers. Some of the issues with the overlay model are discussed in [AWD2].
ATM上でIPを使用してオーバーレイモデルが増大操作の複雑さとコストをもたらす異なる技術（IPやATM）を有する2つの別々のネットワークの管理を必要とします。隣接関係の総数がルータの数の二次関数となるようにフルメッシュオーバレイモデルでは、各ルータは、ネットワーク内の他のすべてのルータにピアであろう。オーバーレイモデルの問題のいくつかは、[AWD2]で議論されています。
Constraint-based routing refers to a class of routing systems that compute routes through a network subject to the satisfaction of a set of constraints and requirements. In the most general setting, constraint-based routing may also seek to optimize overall network performance while minimizing costs.
制約ベースのルーティングは、制約および要件のセットを満足するネットワーク被写体を介してルートを計算するルーティングシステムのクラスを指します。最も一般的な設定では、制約ベースのルーティングは、コストを最小限に抑えながら、ネットワーク全体のパフォーマンスを最適化するために求めることができます。
The constraints and requirements may be imposed by the network itself or by administrative policies. Constraints may include bandwidth, hop count, delay, and policy instruments such as resource class attributes. Constraints may also include domain specific attributes of certain network technologies and contexts which impose restrictions on the solution space of the routing function. Path oriented technologies such as MPLS have made constraint-based routing feasible and attractive in public IP networks.
制約と要件は、ネットワーク自体によって、または管理ポリシーによって課さすることができます。制約は、帯域幅、ホップ数、遅延、およびリソースクラス属性などの政策手段を備えることができます。制約はまた、ルーティング機能の解空間に制限を課し、特定のネットワーク技術とコンテキストのドメイン固有の属性を含むことができます。 MPLSなどの経路指向技術は、公衆IP網における制約ベースのルーティングが可能と魅力行きました。
The concept of constraint-based routing within the context of MPLS traffic engineering requirements in IP networks was first defined in [RFC-2702].
IPネットワークでMPLSトラフィックエンジニアリング要件の文脈の中で制約ベースのルーティングの概念は、最初の[RFC-2702]で定義されました。
Unlike QoS routing (for example, see [RFC-2386] and [MA]) which generally addresses the issue of routing individual traffic flows to satisfy prescribed flow based QoS requirements subject to network resource availability, constraint-based routing is applicable to traffic aggregates as well as flows and may be subject to a wide variety of constraints which may include policy restrictions.
QoSは、ルーティングとは異なり、一般的に、個々のトラフィックのルーティングの問題を解決し、ネットワークリソースの空き状況に所定のフローベースのQoS要件を満たすように流れる（例えば、[RFC-2386]及び[MA]を参照）は、制約ベースのルーティングは、トラフィック凝集体にも適用可能です同様に流れ、ポリシーの制限を含むことができる制約の多種多様の対象とすることができます。
This subsection reviews a number of IETF activities pertinent to Internet traffic engineering. These activities are primarily intended to evolve the IP architecture to support new service definitions which allow preferential or differentiated treatment to be accorded to certain types of traffic.
ここでは、インターネットトラフィックエンジニアリングに関連するIETF活動の数をレビュー。これらの活動は、主に優遇または差別治療は特定の種類のトラフィックに従うことを可能にする新しいサービス定義をサポートするために、IPアーキテクチャを進化させることを意図しています。
The IETF Integrated Services working group developed the integrated services (Intserv) model. This model requires resources, such as bandwidth and buffers, to be reserved a priori for a given traffic flow to ensure that the quality of service requested by the traffic flow is satisfied. The integrated services model includes additional components beyond those used in the best-effort model such as packet classifiers, packet schedulers, and admission control. A packet classifier is used to identify flows that are to receive a certain level of service. A packet scheduler handles the scheduling of service to different packet flows to ensure that QoS commitments are met. Admission control is used to determine whether a router has the necessary resources to accept a new flow.
IETF統合サービスワーキンググループは、統合サービス（IntServの）モデルを開発しました。このモデルは、帯域幅やバッファなどのリソースは、トラフィックフローによって要求されたサービスの品質が満たされることを保証するために与えられたトラフィックフローのために先験的に予約することが必要です。統合サービスモデルは、パケットの分類、パケットスケジューラ、およびアドミッション制御として、ベストエフォート型のモデルで使用されるものを超えて追加のコンポーネントが含まれています。パケット分類は、サービスの特定のレベルを受信するようにされたフローを識別するために使用されます。パケットスケジューラは、QoSコミットメントが満たされていることを確認するために、異なるパケットフローへのサービスのスケジューリングを処理します。アドミッション制御は、ルータが新しい流れを受け入れるために必要なリソースを持っているかどうかを決定するために使用されます。
Two services have been defined under the Integrated Services model: guaranteed service [RFC-2212] and controlled-load service [RFC-2211].
保証サービス[RFC-2212]と制御されたロード・サービス[RFC-2211]：2つのサービスは、サービス統合型モデルで定義されています。
The guaranteed service can be used for applications requiring bounded packet delivery time. For this type of application, data that is delivered to the application after a pre-defined amount of time has elapsed is usually considered worthless. Therefore, guaranteed service was intended to provide a firm quantitative bound on the end-to-end packet delay for a flow. This is accomplished by controlling the queuing delay on network elements along the data flow path. The guaranteed service model does not, however, provide bounds on jitter (inter-arrival times between consecutive packets).
保証されたサービスは、有界パケット配信時間を必要とする用途に使用することができます。このタイプのアプリケーションのために、時間の事前定義された量が経過した後にアプリケーションに配信されるデータは、通常、無価値であると考えられます。そのため、保証されたサービスは、フローのエンドツーエンドのパケット遅延にバインドしっかり定量を提供することを意図していました。これは、データ・フロー・パスに沿ってネットワーク要素上のキューイング遅延を制御することによって達成されます。保証サービスモデルは、しかし、ジッタの範囲（連続したパケット間の相互到着時間）を提供していません。
The controlled-load service can be used for adaptive applications that can tolerate some delay but are sensitive to traffic overload conditions. This type of application typically functions satisfactorily when the network is lightly loaded but its performance degrades significantly when the network is heavily loaded. Controlled-load service, therefore, has been designed to provide approximately the same service as best-effort service in a lightly loaded network regardless of actual network conditions. Controlled-load service is described qualitatively in that no target values of delay or loss are specified.
制御されたロード・サービスは、いくつかの遅延を許容することができ、適応型アプリケーションのために使用されるが、トラフィックの過負荷状態に敏感であることができます。ネットワークの負荷が軽いときにこのタイプのアプリケーションは、通常、満足に機能しますが、ネットワークの負荷が高いときにパフォーマンスが大幅に低下します。制御されたロード・サービス、したがって、関係なく、実際のネットワーク環境の負荷の軽いネットワークでは、ほぼ同じサービスとして、ベストエフォート型のサービスを提供するように設計されています。制御負荷サービスは、遅延または損失のない目標値が指定されていないことを定性的に記載されています。
The main issue with the Integrated Services model has been scalability [RFC-2998], especially in large public IP networks which may potentially have millions of active micro-flows in transit concurrently.
統合サービス・モデルの主な問題は、特に、潜在的に同時に輸送中のアクティブマイクロフローの何百万を有することができる大規模な公共のIPネットワークにおいて、スケーラビリティ[RFC-2998]でした。
A notable feature of the Integrated Services model is that it requires explicit signaling of QoS requirements from end systems to routers [RFC-2753]. The Resource Reservation Protocol (RSVP) performs this signaling function and is a critical component of the Integrated Services model. The RSVP protocol is described next.
サービス統合型モデルの顕著な特徴は、それがルータ[RFC-2753]にエンドシステムからのQoS要件の明示的なシグナリングを必要とすることです。リソース予約プロトコル（RSVP）は、このシグナリング機能を実行し、統合サービスモデルの重要な要素です。 RSVPプロトコルについて説明します。
RSVP is a soft state signaling protocol [RFC-2205]. It supports receiver initiated establishment of resource reservations for both multicast and unicast flows. RSVP was originally developed as a signaling protocol within the integrated services framework for applications to communicate QoS requirements to the network and for the network to reserve relevant resources to satisfy the QoS requirements [RFC-2205].
RSVPは、ソフト状態シグナリングプロトコル[RFC-2205]です。これは、マルチキャストとユニキャストのフローの両方のためのリソース予約の受信を開始設立をサポートしています。 RSVPは、もともとネットワークにQoS要件を通信するアプリケーションおよびQoS要件[RFC-2205]満たすために、関連するリソースを予約するネットワークのための統合サービスフレームワーク内のシグナリングプロトコルとして開発されました。
Under RSVP, the sender or source node sends a PATH message to the receiver with the same source and destination addresses as the traffic which the sender will generate. The PATH message contains: (1) a sender Tspec specifying the characteristics of the traffic, (2) a sender Template specifying the format of the traffic, and (3) an optional Adspec which is used to support the concept of one pass with advertising" (OPWA) [RFC-2205]. Every intermediate router along the path forwards the PATH Message to the next hop determined by the routing protocol. Upon receiving a PATH Message, the receiver responds with a RESV message which includes a flow descriptor used to request resource reservations. The RESV message travels to the sender or source node in the opposite direction along the path that the PATH message traversed. Every intermediate router along the path can reject or accept the reservation request of the RESV message. If the request is rejected, the rejecting router will send an error message to the receiver and the signaling process will terminate. If the request is accepted, link bandwidth and buffer space are allocated for the flow and the related flow state information is installed in the router.
RSVPの下で、送信者または送信元ノードは、送信者が生成するトラフィックと同じ送信元および宛先アドレスを持つ受信機にPATHメッセージを送信します。 PATHメッセージが含まれていますトラフィックの特性を指定する（1）送信者Tspecは、（2）広告とワンパスの概念をサポートするために使用されるトラフィックのフォーマットを指定する送信者テンプレート、および（3）任意ADSPEC 「（OPWA）[RFC-2205]。パスに沿った全ての中間ルータは、ルーティングプロトコルによって決定された次のホップにPATHメッセージを転送する。PATHメッセージを受信すると、受信機は、に使用されるフロー記述子を含むRESVメッセージで応答要求リソース予約するRESVメッセージは、PATHメッセージが横断するパスに沿って反対方向に送信者またはソースノードに移動する。パスに沿った全ての中間ルータは、RESVメッセージの予約要求を拒否するか、受け入れることができる。要求が拒否された場合、拒否ルータは、受信機にエラーメッセージを送信し、シグナリング処理が終了する。要求が受け入れられた場合、リンク帯域幅とバッファ空間がフローに対して割り当てと関連していますdフロー状態情報は、ルータに搭載されています。
One of the issues with the original RSVP specification was Scalability. This is because reservations were required for micro-flows, so that the amount of state maintained by network elements tends to increase linearly with the number of micro-flows. These issues are described in [RFC-2961].
オリジナルのRSVP仕様の問題の一つは、スケーラビリティでした。ネットワーク要素によって維持される状態の量は、マイクロフローの数と共に直線的に増加する傾向があるように予約が、マイクロフローのために必要であったためです。これらの問題は、[RFC-2961]で説明されています。
Recently, RSVP has been modified and extended in several ways to mitigate the scaling problems. As a result, it is becoming a versatile signaling protocol for the Internet. For example, RSVP has been extended to reserve resources for aggregation of flows, to set up MPLS explicit label switched paths, and to perform other signaling functions within the Internet. There are also a number of proposals to reduce the amount of refresh messages required to maintain established RSVP sessions [RFC-2961].
最近では、RSVPは、変更とスケーリングの問題を軽減するには、いくつかの方法で拡張されました。その結果、それはインターネットのための多目的シグナリングプロトコルになりつつあります。例えば、RSVPフローの集合のためのリソースを予約するように拡張された、MPLSを設定する明示的なラベルは、パスを切り替え、およびインターネット内の他のシグナリング機能を実行します。確立されたRSVPセッション[RFC-2961]を維持するために必要なリフレッシュメッセージの量を減らすために多くの提案もあります。
A number of IETF working groups have been engaged in activities related to the RSVP protocol. These include the original RSVP working group, the MPLS working group, the Resource Allocation Protocol working group, and the Policy Framework working group.
IETFワーキンググループの数は、RSVPプロトコルに関連する活動に従事してきました。これらは、元のRSVPワーキンググループ、MPLSワーキンググループ、リソース割り当てプロトコルワーキンググループ、およびポリシーフレームワークワーキンググループが含まれます。
The goal of the Differentiated Services (Diffserv) effort within the IETF is to devise scalable mechanisms for categorization of traffic into behavior aggregates, which ultimately allows each behavior aggregate to be treated differently, especially when there is a shortage of resources such as link bandwidth and buffer space [RFC-2475]. One of the primary motivations for the Diffserv effort was to devise alternative mechanisms for service differentiation in the Internet that mitigate the scalability issues encountered with the Intserv model.
IETF内の差別化サービス（DiffServ）の努力の目標は、最終的に各行動の集合体は、このようなリンク帯域幅およびなどのリソースの不足している場合は特に、別々に扱うことができます行動の集合体へのトラフィックの分類のためのスケーラブルなメカニズムを考案することですバッファスペース[RFC-2475]。 Diffservの努力のための主な動機の一つは、IntServのモデルと遭遇した拡張性の問題を軽減するため、インターネットでのサービスの差別化のための代替メカニズムを考案しました。
The IETF Diffserv working group has defined a Differentiated Services field in the IP header (DS field). The DS field consists of six bits of the part of the IP header formerly known as TOS octet. The DS field is used to indicate the forwarding treatment that a packet should receive at a node [RFC-2474]. The Diffserv working group has also standardized a number of Per-Hop Behavior (PHB) groups. Using the PHBs, several classes of services can be defined using different classification, policing, shaping, and scheduling rules.
IETFのDiffservワーキンググループは、IPヘッダ（DSフィールド）で差別化サービスフィールドを定義しています。 DSフィールドは、以前TOSオクテットとして知られているIPヘッダの一部の6ビットから成ります。 DSフィールドは、パケットがノード[RFC-2474]で受けるべき転送処理を示すために使用されます。 Diffservのワーキンググループは、ホップ単位動作（PHB）グループの数を標準化しました。 PHBを使用して、サービスのいくつかのクラスは、異なる分類、ポリシング、シェーピング、およびスケジューリングルールを使用して定義することができます。
For an end-user of network services to receive Differentiated Services from its Internet Service Provider (ISP), it may be necessary for the user to have a Service Level Agreement (SLA) with the ISP. An SLA may explicitly or implicitly specify a Traffic Conditioning Agreement (TCA) which defines classifier rules as well as metering, marking, discarding, and shaping rules.
ネットワークサービスのエンドユーザーがそのインターネットサービスプロバイダ（ISP）から差別化サービスを受けるためには、ユーザーがISPとのサービスレベル契約（SLA）を持っているため、それが必要な場合があります。 SLAは、明示的または暗黙的に、マーキング廃棄、およびルールを成形、計量並びに分類器規則を定義するトラフィックコンディショニング契約（TCA）を指定することができます。
Packets are classified, and possibly policed and shaped at the ingress to a Diffserv network. When a packet traverses the boundary between different Diffserv domains, the DS field of the packet may be re-marked according to existing agreements between the domains.
パケットが分類され、おそらくはポリシングとDiffservネットワークへの入口で成形されます。パケットが異なるたDiffservドメイン間の境界を横断するとき、パケットのDSフィールドは、ドメイン間の既存の協定に基づいて再マークされることがあります。
Differentiated Services allows only a finite number of service classes to be indicated by the DS field. The main advantage of the Diffserv approach relative to the Intserv model is scalability. Resources are allocated on a per-class basis and the amount of state information is proportional to the number of classes rather than to the number of application flows.
差別化サービスは、サービスクラスの唯一の有限数は、DSフィールドによって示されることを可能にします。 IntServモデルにDiffservのアプローチに対する主な利点はスケーラビリティです。リソースは、クラス単位で割り当てられ、状態情報の量は、クラスの数ではなく、アプリケーションフローの数に比例します。
It should be obvious from the previous discussion that the Diffserv model essentially deals with traffic management issues on a per hop basis. The Diffserv control model consists of a collection of micro-TE control mechanisms. Other traffic engineering capabilities, such as capacity management (including routing control), are also required in order to deliver acceptable service quality in Diffserv networks. The concept of Per Domain Behaviors has been introduced to better capture the notion of differentiated services across a complete domain [RFC-3086].
これは、Diffservのモデルは、基本的に、ホップごとにトラフィック管理の問題を扱う前の説明から明らかです。 Diffservの制御モデルは、マイクロTE制御機構の集合から成ります。このような（ルーティング制御を含む）容量管理などの他のトラフィックエンジニアリング機能は、また、Diffservのネットワークで許容されるサービス品質を提供するために必要とされます。ドメイン単位行動の概念が良く、完全なドメイン[RFC-3086]全体で差別化されたサービスの概念をキャプチャするために導入されました。
MPLS is an advanced forwarding scheme which also includes extensions to conventional IP control plane protocols. MPLS extends the Internet routing model and enhances packet forwarding and path control [RFC-3031].
MPLSはまた、従来のIP制御プレーンプロトコルへの拡張を含む、高度な転送方式です。 MPLSは、インターネット・ルーティング・モデルを拡張し、パケット転送と経路制御[RFC-3031]を増強します。
At the ingress to an MPLS domain, label switching routers (LSRs) classify IP packets into forwarding equivalence classes (FECs) based on a variety of factors, including, e.g., a combination of the information carried in the IP header of the packets and the local routing information maintained by the LSRs. An MPLS label is then prepended to each packet according to their forwarding equivalence classes. In a non-ATM/FR environment, the label is 32 bits long and contains a 20-bit label field, a 3-bit experimental field (formerly known as Class-of-Service or CoS field), a 1-bit label stack indicator and an 8-bit TTL field. In an ATM (FR) environment, the label consists of information encoded in the VCI/VPI (DLCI) field. An MPLS capable router (an LSR) examines the label and possibly the experimental field and uses this information to make packet forwarding decisions.
MPLSドメインの入口で、ラベルスイッチングルータ（LSRの）を含む、種々の要因に基づいて、等価クラス（のFEC）を転送中にIPパケットを分類し、例えば、パケットのIPヘッダで運ばれた情報の組み合わせとLSRによって維持されるローカルルーティング情報。 MPLSラベルは、その後彼らのフォワーディング等価クラスに応じて、各パケットの先頭に付加されます。非ATM / FR環境では、ラベルは、32ビット長であり、20ビット・ラベル・フィールド、1ビットのラベルスタック（以前のサービスクラスまたはCoSフィールドとして知られている）3ビットの実験フィールドを含みますインジケータ8ビットのTTLフィールド。 ATM（FR）環境では、ラベルは、VCI / VPI（DLCI）フィールドに符号化された情報で構成されています。 MPLS対応ルータ（LSR）は、ラベルと、おそらく実験的なフィールドを調べて、パケット転送決定を行うために、この情報を使用しています。
An LSR makes forwarding decisions by using the label prepended to packets as the index into a local next hop label forwarding entry (NHLFE). The packet is then processed as specified in the NHLFE. The incoming label may be replaced by an outgoing label, and the packet may be switched to the next LSR. This label-switching process is very similar to the label (VCI/VPI) swapping process in ATM networks. Before a packet leaves an MPLS domain, its MPLS label may be removed. A Label Switched Path (LSP) is the path between an ingress LSRs and an egress LSRs through which a labeled packet traverses. The path of an explicit LSP is defined at the originating (ingress) node of the LSP. MPLS can use a signaling protocol such as RSVP or LDP to set up LSPs.
LSRは、ローカルネクストホップラベル転送エントリ（NHLFE）へのインデックスとして、パケットの先頭に付けたラベルを使用して転送を決定します。 NHLFEで指定されたパケットが処理されます。着信ラベルが出力ラベルで置き換えられてもよく、パケットは次のLSRに切り替えることができます。このラベルスイッチングプロセスは、ATMネットワークにおけるラベル（VCI / VPI）スワッピングプロセスに非常に似ています。パケットがMPLSドメインを離れる前に、そのMPLSラベルを除去することができます。ラベルスイッチパス（LSP）は、入口のLSRと標識されたパケットが横断するを通して出口LSRs間の経路です。明示的にLSPの経路は、LSPの発信元（入力）ノードで定義されています。 MPLSは、そのようなLSPを設定するためのRSVPまたはLDPとしてシグナリングプロトコルを使用することができます。
MPLS is a very powerful technology for Internet traffic engineering because it supports explicit LSPs which allow constraint-based routing to be implemented efficiently in IP networks [AWD2]. The requirements for traffic engineering over MPLS are described in [RFC-2702]. Extensions to RSVP to support instantiation of explicit LSP are discussed in [RFC-3209]. Extensions to LDP, known as CR-LDP, to support explicit LSPs are presented in [JAM].
それは、制約ベースのルーティングは、IPネットワーク[AWD2]で効率的に実装できるように、明示的なLSPをサポートしているので、MPLSは、インターネットトラフィックエンジニアリングのための非常に強力な技術です。 MPLS上のトラフィックエンジニアリングのための要件は、[RFC-2702]で説明されています。明示的にLSPのインスタンスをサポートするために、RSVPの拡張機能は、[RFC-3209]で議論されています。明示的にLSPをサポートするためのCR-LDPとして知られているLDPの拡張は、[JAM]に提示されています。
The IETF IP Performance Metrics (IPPM) working group has been developing a set of standard metrics that can be used to monitor the quality, performance, and reliability of Internet services. These metrics can be applied by network operators, end-users, and independent testing groups to provide users and service providers with a common understanding of the performance and reliability of the Internet component 'clouds' they use/provide [RFC-2330]. The criteria for performance metrics developed by the IPPM WG are described in [RFC-2330]. Examples of performance metrics include one-way packet loss [RFC-2680], one-way delay [RFC-2679], and connectivity measures between two nodes [RFC-2678]. Other metrics include second-order measures of packet loss and delay.
IETF IPパフォーマンス・メトリック（IPPM）ワーキンググループは、インターネットサービスの品質、パフォーマンス、および信頼性を監視するために使用することができる標準的なメトリックのセットを開発してきました。これらのメトリックは、彼らが/使用のインターネットコンポーネントの雲」の性能と信頼性の共通の理解を持つユーザーやサービスプロバイダを提供するために、ネットワーク事業者、エンドユーザー、および独立したテスト・グループによって適用することができます提供[RFC-2330]。 IPPM WGによって開発された性能指標の基準は、[RFC-2330]に記載されています。パフォーマンス・メトリックの例は、一方向のパケット損失[RFC-2680]、一方向遅延[RFC-2679]、2つのノード[RFC-2678]との間の接続性尺度を含みます。その他のメトリックは、パケットロスや遅延の二次措置が含まれます。
Some of the performance metrics specified by the IPPM WG are useful for specifying Service Level Agreements (SLAs). SLAs are sets of service level objectives negotiated between users and service providers, wherein each objective is a combination of one or more performance metrics, possibly subject to certain constraints.
IPPM WGによって指定されたパフォーマンス・メトリックの一部は、サービス・レベル・アグリーメント（SLA）を指定するために有用です。 SLAはそれぞれ目的が特定の制約におそらく被験者一つ以上の性能メトリクスの組み合わせである、ユーザとサービスプロバイダとの間で交渉されたサービスレベル目標のセットです。
The IETF Real Time Flow Measurement (RTFM) working group has produced an architecture document defining a method to specify traffic flows as well as a number of components for flow measurement (meters, meter readers, manager) [RFC-2722]. A flow measurement system enables network traffic flows to be measured and analyzed at the flow level for a variety of purposes. As noted in RFC 2722, a flow measurement system can be very useful in the following contexts: (1) understanding the behavior of existing networks, (2) planning for network development and expansion, (3) quantification of network performance, (4) verifying the quality of network service, and (5) attribution of network usage to users.
IETFリアルタイム流量測定（RTFM）ワーキンググループは、トラフィックフローを指定する方法を定義するアーキテクチャ文書ならびに流量測定（メートル、メートルリーダー、マネージャ）[RFC-2722]のための部品の数を生産しています。流量測定システムは、ネットワークトラフィックを測定し、様々な目的のためのフローレベルで分析することが流れる可能となります。 RFC 2722に述べたように、流量測定システムは、以下の状況で非常に有用であり得る：（1）既存のネットワークの挙動を理解すること、ネットワークの開発および展開のために（2）プランニング、ネットワーク性能の（3）の定量化、（4）ユーザへのネットワークサービスの品質、およびネットワーク利用の（5）属性を検証します。
A flow measurement system consists of meters, meter readers, and managers. A meter observes packets passing through a measurement point, classifies them into certain groups, accumulates certain usage data (such as the number of packets and bytes for each group), and stores the usage data in a flow table. A group may represent a user application, a host, a network, a group of networks, etc. A meter reader gathers usage data from various meters so it can be made available for analysis. A manager is responsible for configuring and controlling meters and meter readers. The instructions received by a meter from a manager include flow specification, meter control parameters, and sampling techniques. The instructions received by a meter reader from a manager include the address of the meter whose date is to be collected, the frequency of data collection, and the types of flows to be collected.
流量測定システムは、メートル、メートルリーダ、およびマネージャから成ります。メータは、測定点を通過するパケットを監視し、特定のグループにそれらを分類し、（例えば、各グループのパケットおよびバイト数のような）特定の使用量データを蓄積し、フローテーブル内の使用量データを記憶します。グループは、それが分析のために利用可能にすることができるように、メーター読者は、種々メートルから使用量データを収集し、ユーザ・アプリケーション、ホスト、ネットワーク、ネットワークのグループなどを表すことができます。管理者は、メーターと検針を設定し、制御するための責任があります。マネージャからメータが受け取った命令は、フロー仕様、メータ制御パラメータ、及びサンプリング技術を含みます。マネージャからメータリーダによって受信された命令は、日付収集される計器のアドレス、データ収集の頻度、および収集されるフローのタイプを含みます。
[RFC-3124] is intended to provide a set of congestion control mechanisms that transport protocols can use. It is also intended to develop mechanisms for unifying congestion control across a subset of an endpoint's active unicast connections (called a congestion group). A congestion manager continuously monitors the state of the path for each congestion group under its control. The manager uses that information to instruct a scheduler on how to partition bandwidth among the connections of that congestion group.
[RFC-3124]は、トランスポートプロトコルが使用できる輻輳制御機構のセットを提供することを意図しています。また、エンドポイントのアクティブなユニキャスト接続（輻輳グループと呼ばれる）のサブセットを横切っ統一輻輳制御のためのメカニズムを開発することを意図しています。輻輳管理は、連続的にその制御下にある各渋滞グループのパスの状態を監視します。管理者は、その渋滞グループの接続間の帯域幅を分割する方法についてスケジューラに指示し、その情報を使用しています。
This section provides an overview of prior work within the ITU-T pertaining to traffic engineering in traditional telecommunications networks.
このセクションでは、ITU-Tは、従来の通信ネットワークにトラフィックエンジニアリングに関する内の前の仕事の概要を説明します。
ITU-T Recommendations E.600 [ITU-E600], E.701 [ITU-E701], and E.801 [ITU-E801] address traffic engineering issues in traditional telecommunications networks. Recommendation E.600 provides a vocabulary for describing traffic engineering concepts, while E.701 defines reference connections, Grade of Service (GOS), and traffic parameters for ISDN. Recommendation E.701 uses the concept of a reference connection to identify representative cases of different types of connections without describing the specifics of their actual realizations by different physical means. As defined in Recommendation E.600, "a connection is an association of resources providing means for communication between two or more devices in, or attached to, a telecommunication network." Also, E.600 defines "a resource as any set of physically or conceptually identifiable entities within a telecommunication network, the use of which can be unambiguously determined" [ITU-E600]. There can be different types of connections as the number and types of resources in a connection may vary.
ITU-T勧告E.600 [ITU-E600]、E.701 [ITU-E701]、およびE.801 [ITU-E801]は、従来の通信ネットワークにおけるトラフィックエンジニアリングの問題に対処します。 E.701は、基準接続、サービスのグレード（GOS）、およびISDNのためのトラフィックパラメータを定義しながら、推薦E.600は、トラフィックエンジニアリングの概念を記述するための語彙を提供します。推薦E.701は、異なる物理的手段によりそれらの実際の実現の詳細を記述することなく、接続の異なる種類の代表的な事例を識別するために、基準接続の概念を使用します。勧告E.600で定義されているように、「接続は、電気通信ネットワーク内の2つの以上のデバイス間の通信のための手段を提供するリソースの関連で、またはに取り付けられます。」また、E.600は[ITU-E600]「の使用が明確に決定することができる通信ネットワーク内の物理的または概念的に識別可能なエンティティの任意のセットとしてリソース」を定義します。接続の数やリソースの種類は変更になる場合がありますような接続のさまざまな種類が存在する場合があります。
Typically, different network segments are involved in the path of a connection. For example, a connection may be local, national, or international. The purposes of reference connections are to clarify and specify traffic performance issues at various interfaces between different network domains. Each domain may consist of one or more service provider networks.
典型的には、異なるネットワークセグメントを接続する経路に関与しています。例えば、接続は、地方、国、または国際的かもしれません。参照接続の目的は、異なるネットワークドメイン間の様々なインターフェースでトラフィックのパフォーマンスの問題を明確に指定することです。各ドメインは、1つ以上のサービスプロバイダのネットワークから構成されてもよいです。
Reference connections provide a basis to define grade of service (GoS) parameters related to traffic engineering within the ITU-T framework. As defined in E.600, "GoS refers to a number of traffic engineering variables which are used to provide a measure of the adequacy of a group of resources under specified conditions." These GoS variables may be probability of loss, dial tone, delay, etc. They are essential for network internal design and operation as well as for component performance specification.
リファレンス接続は、ITU-Tの枠組みの中でトラフィックエンジニアリングに関連するサービス（GOS）のパラメータのグレードを定義するための基礎を提供します。 E.600で定義されているように、「GOSが指定された条件の下でリソースのグループの妥当性の尺度を提供するために使用されるトラフィックエンジニアリング変数の数を指します。」これらのGoS変数は、損失の可能性もトーン、遅延、など彼らは、ネットワーク内部の設計及び動作のためだけでなく、部品の性能仕様に不可欠なをダイヤルすることができます。
GoS is different from quality of service (QoS) in the ITU framework. QoS is the performance perceivable by a telecommunication service user and expresses the user's degree of satisfaction of the service. QoS parameters focus on performance aspects observable at the service access points and network interfaces, rather than their causes within the network. GoS, on the other hand, is a set of network oriented measures which characterize the adequacy of a group of resources under specified conditions. For a network to be effective in serving its users, the values of both GoS and QoS parameters must be related, with GoS parameters typically making a major contribution to the QoS.
GOSがITUの枠組みにおけるサービスの品質（QoS）と異なっています。 QoSは、電気通信サービス利用者がパフォーマンスの知覚であり、サービスの満足度の利用者の程度を表します。 QoSパラメータは、サービス・アクセス・ポイントとネットワーク・インターフェースではなく、ネットワーク内のそれらの原因で観察性能側面に焦点を当てます。 GOSが、他方で、指定された条件の下でリソースのグループの妥当性を特徴付けるネットワーク志向の措置のセットです。ネットワークは、そのユーザーにサービスを提供するのに有効であるために、両方のGoSおよびQoSパラメータの値は、のGoSパラメータは、典型的なQoSの主要な貢献を行うとともに、関連していなければなりません。
Recommendation E.600 stipulates that a set of GoS parameters must be selected and defined on an end-to-end basis for each major service category provided by a network to assist the network provider with improving efficiency and effectiveness of the network. Based on a selected set of reference connections, suitable target values are assigned to the selected GoS parameters under normal and high load conditions. These end-to-end GoS target values are then apportioned to individual resource components of the reference connections for dimensioning purposes.
推薦E.600はのGoSパラメータのセットを選択してネットワークの効率と効果を向上させるとネットワークプロバイダを支援するために、ネットワークによって提供される主要な各サービスカテゴリのためのエンドツーエンドに基づいて定義されなければならないことを規定しています。参照接続の選択されたセットに基づいて、適切な目標値は、通常、高負荷条件下での選択のGoSパラメータに割り当てられています。これらのエンド・ツー・エンドのGoS目標値は、寸法の目的のために参照接続の個々のリソースの構成要素に配分されています。
The Internet is dominated by client-server interactions, especially Web traffic (in the future, more sophisticated media servers may become dominant). The location and performance of major information servers has a significant impact on the traffic patterns within the Internet as well as on the perception of service quality by end users.
インターネットは、クライアントサーバの相互作用、特にWebトラフィック（将来的には、より洗練されたメディアサーバーが支配的になる場合があります）によって支配されています。主要な情報サーバの場所とパフォーマンスは、インターネット内だけでなく、エンドユーザーによるサービスの質の知覚にトラフィックパターンに大きな影響を与えます。
A number of dynamic load balancing techniques have been devised to improve the performance of replicated information servers. These techniques can cause spatial traffic characteristics to become more dynamic in the Internet because information servers can be dynamically picked based upon the location of the clients, the location of the servers, the relative utilization of the servers, the relative performance of different networks, and the relative performance of different parts of a network. This process of assignment of distributed servers to clients is called Traffic Directing. It functions at the application layer.
動的負荷分散技術の数は、複製された情報サーバのパフォーマンスを改善するために考案されてきました。情報サーバが動的にクライアントの場所、サーバーの場所、サーバの相対的な利用、異なるネットワークの相対的なパフォーマンスに基づいて撮像することができるので、これらの技術は、空間的トラフィック特性は、インターネットでよりダイナミックになることを引き起こす可能性があり、ネットワークの異なる部分の相対的な性能。クライアントに配布サーバの割り当てのこのプロセスは、トラフィック監督と呼ばれています。これは、アプリケーション層で機能します。
Traffic Directing schemes that allocate servers in multiple geographically dispersed locations to clients may require empirical network performance statistics to make more effective decisions. In the future, network measurement systems may need to provide this type of information. The exact parameters needed are not yet defined.
クライアントに複数の地理的に分散した場所にあるサーバーを割り当てるトラフィック演出スキームは、より効果的な意思決定を行うために経験的なネットワークパフォーマンス統計が必要な場合があります。将来的には、ネットワーク測定システムは、この種の情報を提供する必要があるかもしれません。必要な正確なパラメータは、まだ定義されていません。
When congestion exists in the network, Traffic Directing and Traffic Engineering systems should act in a coordinated manner. This topic is for further study.
輻輳がネットワーク内に存在する場合、トラフィック向け、トラフィックエンジニアリングシステムが協調して行動しなければなりません。このトピックでは、今後の検討課題です。
The issues related to location and replication of information servers, particularly web servers, are important for Internet traffic engineering because these servers contribute a substantial proportion of Internet traffic.
これらのサーバーは、インターネットトラフィックのかなりの割合を貢献するための位置情報サーバ、特にWebサーバの複製に関連する問題は、インターネットトラフィックエンジニアリングのために重要です。
This section presents a short taxonomy of traffic engineering systems. A taxonomy of traffic engineering systems can be constructed based on traffic engineering styles and views as listed below:
このセクションでは、トラフィックエンジニアリングシステムの短い分類法を提示します。以下に示すようトラフィックエンジニアリングシステムの分類は、トラフィックエンジニアリングのスタイルとビューに基づいて構築することができます。
- Time-dependent vs State-dependent vs Event-dependent - Offline vs Online - Centralized vs Distributed - Local vs Global Information - Prescriptive vs Descriptive - Open Loop vs Closed Loop - Tactical vs Strategic
- 時間依存状態依存イベントに依存対対 - オンライン対オフライン - 分散対集中化 - グローバル情報対ローカル - 閉ループ対開ループ - - 記述対規範戦略対戦術
These classification systems are described in greater detail in the following subsections of this document.
これらの分類システムは、このドキュメントの以下のサブセクションでより詳細に記載されています。
Traffic engineering methodologies can be classified as time-dependent, or state-dependent, or event-dependent. All TE schemes are considered to be dynamic in this document. Static TE implies that no traffic engineering methodology or algorithm is being applied.
トラフィックエンジニアリングの方法論は、時間依存、または状態依存、またはイベントに依存するように分類することができます。すべてのTEのスキームは、この文書に記載されているダイナミックであると考えられています。静的TEは、トラフィックエンジニアリング手法やアルゴリズムが適用されていないことを意味します。
In the time-dependent TE, historical information based on periodic variations in traffic, (such as time of day), is used to pre-program routing plans and other TE control mechanisms. Additionally, customer subscription or traffic projection may be used. Pre-programmed routing plans typically change on a relatively long time scale (e.g., diurnal). Time-dependent algorithms do not attempt to adapt to random variations in traffic or changing network conditions. An example of a time-dependent algorithm is a global centralized optimizer where the input to the system is a traffic matrix and multi-class QoS requirements as described [MR99].
時間依存TE、（例えば、一日の時間のような）トラフィックの周期的変化に基づいて、履歴情報に、計画および他のTE制御機構をルーティングプログラムを事前に使用されます。また、顧客のサブスクリプションまたはトラフィックの投影を使用することができます。予めプログラムされたルーティング計画は、典型的には、比較的長い時間スケール（例えば、日周）に変更します。時間依存するアルゴリズムは、トラフィックやネットワーク状態の変化にランダムな変化に適応しようとしません。時間に依存するアルゴリズムの例が記載されているように、システムへの入力は[MR99]トラフィック行列及びマルチクラスのQoS要件であるグローバル集中オプティマイザです。
State-dependent TE adapts the routing plans for packets based on the current state of the network. The current state of the network provides additional information on variations in actual traffic (i.e., perturbations from regular variations) that could not be predicted using historical information. Constraint-based routing is an example of state-dependent TE operating in a relatively long time scale. An example operating in a relatively short time scale is a load-balancing algorithm described in [MATE].
状態依存TEは、ネットワークの現在の状態に基づいてパケットのルーティング計画を適応させます。ネットワークの現在の状態は、実際のトラフィックの変動に関する追加情報を提供する（すなわち、規則的変動からの摂動）履歴情報を用いて予測することができませんでした。制約ベースのルーティングは、比較的長い時間スケールで動作する状態依存TEの一例です。比較的短い時間スケールで動作する例では、[MATE]に記載の負荷分散アルゴリズムです。
The state of the network can be based on parameters such as utilization, packet delay, packet loss, etc. These parameters can be obtained in several ways. For example, each router may flood these parameters periodically or by means of some kind of trigger to other routers. Another approach is for a particular router performing adaptive TE to send probe packets along a path to gather the state of that path. Still another approach is for a management system to gather relevant information from network elements.
ネットワークの状態は、これらのパラメータは、いくつかの方法で得ることができる等の利用、パケット遅延、パケット損失、などのパラメータに基づくことができます。例えば、各ルータは、定期的に、または他のルータへのトリガのいくつかの種類によって、これらのパラメータをあふれさせることがあります。別のアプローチは、そのパスの状態を収集する経路に沿ってプローブパケットを送信するように適応TEを実行する特定のルータのためのものです。管理システムは、ネットワーク要素から関連情報を収集するためのさらに別のアプローチです。
Expeditious and accurate gathering and distribution of state information is critical for adaptive TE due to the dynamic nature of network conditions. State-dependent algorithms may be applied to increase network efficiency and resilience. Time-dependent algorithms are more suitable for predictable traffic variations. On the other hand, state-dependent algorithms are more suitable for adapting to the prevailing network state.
状態情報の迅速かつ正確に収集および配布は、ネットワーク状態の動的な性質に適応TEのために重要です。状態依存型アルゴリズムは、ネットワーク効率と回復力を高めるために適用されてもよいです。時間依存のアルゴリズムは、予測可能なトラフィック変動に適しています。一方、状態依存アルゴリズムは優勢なネットワーク状態への適応のために適しています。
Event-dependent TE methods can also be used for TE path selection. Event-dependent TE methods are distinct from time-dependent and state-dependent TE methods in the manner in which paths are selected. These algorithms are adaptive and distributed in nature and typically use learning models to find good paths for TE in a network. While state-dependent TE models typically use available-link-bandwidth (ALB) flooding for TE path selection, event-dependent TE methods do not require ALB flooding. Rather, event-dependent TE methods typically search out capacity by learning models, as in the success-to-the-top (STT) method. ALB flooding can be resource intensive, since it requires link bandwidth to carry LSAs, processor capacity to process LSAs, and the overhead can limit area/autonomous system (AS) size. Modeling results suggest that event-dependent TE methods could lead to a reduction in ALB flooding overhead without loss of network throughput performance [ASH3].
イベント依存TE法はまた、TEパス選択のために使用することができます。イベント依存TE法は、経路が選択されるように時間依存性と状態依存TE法は異なります。これらのアルゴリズムは、適応と自然に分布しており、典型的には、ネットワークにTEのための良いパスを見つけるために、学習モデルを使用します。状態依存TEモデルは通常、TEパスの選択可能なリンク帯域幅（ALB）フラッディングを使用していますが、イベントに依存するTEメソッドは、ALB氾濫を必要としません。むしろ、イベント依存TEの方法は、典型的には成功ツー・トップ（STT）方式のように、モデルを学習することによって、容量を探し出します。それはのLSA、LSAを処理するプロセッサの能力、およびオーバーヘッドを運ぶためにリンク帯域幅を必要とするのでALBフラッディングはエリア/自律システム（AS）のサイズを制限することができ、リソースを大量に消費することができます。モデリングの結果は、そのイベントに依存するTEメソッドは、ネットワークのスループット性能[AsH 3]の損失なしALB氾濫のオーバーヘッドの削減につながる可能性が示唆されました。
Traffic engineering requires the computation of routing plans. The computation may be performed offline or online. The computation can be done offline for scenarios where routing plans need not be executed in real-time. For example, routing plans computed from forecast information may be computed offline. Typically, offline computation is also used to perform extensive searches on multi-dimensional solution spaces.
トラフィックエンジニアリングは、ルーティング計画の計算を必要とします。計算はオフラインまたはオンラインで実行することができます。計算は、ルーティング計画はリアルタイムで実行する必要はないシナリオのためにオフラインで行うことができます。例えば、予測情報から計算されたルーティング計画はオフラインで計算することができます。典型的には、オフライン計算はまた、多次元ソリューションスペースに広範な検索を実行するために使用されます。
Online computation is required when the routing plans must adapt to changing network conditions as in state-dependent algorithms. Unlike offline computation (which can be computationally demanding), online computation is geared toward relative simple and fast calculations to select routes, fine-tune the allocations of resources, and perform load balancing.
ルーティング計画は状態依存のアルゴリズムのようにネットワークの状況の変化に適応しなければならないとき、オンライン計算が必要です。 （計算上厳しいことができます）オフラインでの計算とは異なり、オンライン計算は微調整リソースの割り当てを、ルートを選択し、負荷分散を実行するために、相対シンプルかつ高速な計算向けです。
Centralized control has a central authority which determines routing plans and perhaps other TE control parameters on behalf of each router. The central authority collects the network-state information from all routers periodically and returns the routing information to the routers. The routing update cycle is a critical parameter directly impacting the performance of the network being controlled. Centralized control may need high processing power and high bandwidth control channels.
集中管理は、各ルータに代わってルーティング計画およびおそらく他のTE制御パラメータを決定する中央の権限を有しています。中央当局は、定期的に全てのルータからネットワーク状態情報を収集し、ルータにルーティング情報を返します。ルーティング更新サイクルは、直接制御され、ネットワークのパフォーマンスに影響を与える重要なパラメータです。集中管理は、高い処理能力と高帯域幅の制御チャネルが必要な場合があります。
Distributed control determines route selection by each router autonomously based on the routers view of the state of the network. The network state information may be obtained by the router using a probing method or distributed by other routers on a periodic basis using link state advertisements. Network state information may also be disseminated under exceptional conditions.
分散制御は、自律的にネットワークの状態のルータのビューに基づいて、各ルータによってルート選択を決定します。ネットワーク状態情報は、プロービング方法を使用してルータによって得られる又はリンクステート広告を使用して、定期的に他のルータによって分散させることができます。ネットワーク状態情報も、例外的な条件の下で普及することができます。
Traffic engineering algorithms may require local or global network-state information.
トラフィックエンジニアリングアルゴリズムは、ローカルまたはグローバルネットワーク状態の情報が必要な場合があります。
Local information pertains to the state of a portion of the domain. Examples include the bandwidth and packet loss rate of a particular path. Local state information may be sufficient for certain instances of distributed-controlled TEs.
ローカル情報はドメインの一部の状態に関係します。例としては、特定のパスの帯域幅およびパケット損失率を含みます。局所的な状態情報は、分散型制御のTEの特定のインスタンスのために十分であってもよいです。
Global information pertains to the state of the entire domain undergoing traffic engineering. Examples include a global traffic matrix and loading information on each link throughout the domain of interest. Global state information is typically required with centralized control. Distributed TE systems may also need global information in some cases.
グローバル情報は、トラフィックエンジニアリングを受けて、ドメイン全体の状態に関係します。例としては、グローバルトラフィックマトリクスを含み、関心のドメイン全体、各リンクの情報を読み込みます。グローバル状態情報は、典型的には、集中制御とが必要です。分散型TEシステムはまた、いくつかのケースではグローバルな情報が必要な場合があります。
TE systems may also be classified as prescriptive or descriptive.
TEシステムは、規範的または記述として分類することができます。
Prescriptive traffic engineering evaluates alternatives and recommends a course of action. Prescriptive traffic engineering can be further categorized as either corrective or perfective. Corrective TE prescribes a course of action to address an existing or predicted anomaly. Perfective TE prescribes a course of action to evolve and improve network performance even when no anomalies are evident.
規範トラフィックエンジニアリングは、代替案を評価し、アクションのコースを推奨しています。規範トラフィックエンジニアリングは、さらに、修正または完全化のいずれかに分類することができます。是正TEは、既存または異常の予測に対処するための行動方針を規定しています。完全化TEは進化し、何の異常が明らかでない場合でも、ネットワークのパフォーマンスを改善するための行動方針を規定しています。
Descriptive traffic engineering, on the other hand, characterizes the state of the network and assesses the impact of various policies without recommending any particular course of action.
記述トラフィックエンジニアリングは、他の一方で、ネットワークの状態を特徴づけると行動のいずれかの特定のコースを推奨することなく、様々な政策の影響を評価します。
Open-loop traffic engineering control is where control action does not use feedback information from the current network state. The control action may use its own local information for accounting purposes, however.
オープンループトラフィックエンジニアリングコントロール制御動作は、現在のネットワークの状態からのフィードバック情報を使用していないところです。制御動作は、しかし、会計目的のために独自のローカル情報を使用することができます。
Closed-loop traffic engineering control is where control action utilizes feedback information from the network state. The feedback information may be in the form of historical information or current measurement.
クローズドループトラフィックエンジニアリングコントロール制御動作は、ネットワークの状態からのフィードバック情報を利用する場合です。フィードバック情報は、履歴情報または電流測定の形態であってもよいです。
Tactical traffic engineering aims to address specific performance problems (such as hot-spots) that occur in the network from a tactical perspective, without consideration of overall strategic imperatives. Without proper planning and insights, tactical TE tends to be ad hoc in nature.
戦術的なトラフィックエンジニアリングは、全体的な戦略的責務を考慮せずに、戦術的な観点から、ネットワークで発生する（例えばホットスポットなど）、特定のパフォーマンスの問題に対処することを目指しています。適切な計画と洞察力がなければ、戦術的なTEは自然の中でアドホックになる傾向があります。
Strategic traffic engineering approaches the TE problem from a more organized and systematic perspective, taking into consideration the immediate and longer term consequences of specific policies and actions.
戦略的なトラフィックエンジニアリングを考慮に具体的な政策や行動の即時かつ長期的な影響を取って、より組織的かつ体系的な観点からTEの問題に近づきます。
This section describes high level recommendations for traffic engineering in the Internet. These recommendations are presented in general terms.
このセクションでは、インターネットにおけるトラフィックエンジニアリングのためのハイレベルの推奨事項について説明します。これらの推奨事項は、一般的な用語で提示されています。
The recommendations describe the capabilities needed to solve a traffic engineering problem or to achieve a traffic engineering objective. Broadly speaking, these recommendations can be categorized as either functional and non-functional recommendations.
勧告は、トラフィックエンジニアリングの問題を解決するために、またはトラフィックエンジニアリングの目的を達成するために必要な機能を説明します。大まかに言えば、これらの勧告は、機能と非機能勧告のいずれかに分類することができます。
Functional recommendations for Internet traffic engineering describe the functions that a traffic engineering system should perform. These functions are needed to realize traffic engineering objectives by addressing traffic engineering problems.
インターネットトラフィックエンジニアリングのための機能的な提言は、トラフィックエンジニアリングシステムが実行すべき機能について説明します。これらの機能は、トラフィックエンジニアリングの問題に取り組むことにより、トラフィックエンジニアリングの目的を実現するために必要とされています。
Non-functional recommendations for Internet traffic engineering relate to the quality attributes or state characteristics of a traffic engineering system. These recommendations may contain conflicting assertions and may sometimes be difficult to quantify precisely.
インターネットトラフィックエンジニアリングのための非機能の推奨事項は、トラフィックエンジニアリングシステムの品質属性や状態の特性に関係します。これらの推奨事項は、矛盾するアサーションを含むことができ、時には正確に定量化することは困難です。
The generic non-functional recommendations for Internet traffic engineering include: usability, automation, scalability, stability, visibility, simplicity, efficiency, reliability, correctness, maintainability, extensibility, interoperability, and security. In a given context, some of these recommendations may be critical while others may be optional. Therefore, prioritization may be required during the development phase of a traffic engineering system (or components thereof) to tailor it to a specific operational context.
インターネットトラフィックエンジニアリングのための一般的な非機能推奨事項が含まれます：ユーザビリティ、自動化、拡張性、安定性、可視性、シンプルさ、効率性、信頼性、正確性、保守性、拡張性、相互運用性、およびセキュリティを。他のものは任意であってもよいしながら、与えられた文脈において、これらの推奨事項のいくつかが重要であり得ます。したがって、優先順位付けは、特定の動作コンテキストにそれを調整するトラフィック・エンジニアリング・システム（またはそのコンポーネント）の開発段階で必要とされ得ます。
In the following paragraphs, some of the aspects of the non-functional recommendations for Internet traffic engineering are summarized.
以下の段落では、インターネットのトラフィックエンジニアリングのための非機能勧告の側面の一部が要約されています。
Usability: Usability is a human factor aspect of traffic engineering systems. Usability refers to the ease with which a traffic engineering system can be deployed and operated. In general, it is desirable to have a TE system that can be readily deployed in an existing network. It is also desirable to have a TE system that is easy to operate and maintain.
ユーザビリティ：ユーザビリティはトラフィックエンジニアリング・システムのヒューマンファクターの観点です。ユーザビリティは、トラフィックエンジニアリングシステムが配備され、操作することができる容易さを意味します。一般的に、容易に既存のネットワークに配備することができるTEシステムを有することが望ましいです。動作し、保守が容易であるTEシステムを有することが望ましいです。
Automation: Whenever feasible, a traffic engineering system should automate as many traffic engineering functions as possible to minimize the amount of human effort needed to control and analyze operational networks. Automation is particularly imperative in large scale public networks because of the high cost of the human aspects of network operations and the high risk of network problems caused by human errors. Automation may entail the incorporation of automatic feedback and intelligence into some components of the traffic engineering system.
オートメーション：たび実現可能な、トラフィックエンジニアリングシステムの運用ネットワークを制御し、分析するために必要な人間の努力の量を最小限に抑えるために、できるだけ多くのトラフィックエンジニアリング機能を自動化する必要があります。自動化は、ネットワークの動作の人間の側面とヒューマンエラーに起因するネットワークの問題の高リスクの高いコストの大規模公衆ネットワークに特に不可欠です。オートメーションは、トラフィックエンジニアリングシステムの一部のコンポーネントに自動フィードバックと知性の取り込みを伴ってもよいです。
Scalability: Contemporary public networks are growing very fast with respect to network size and traffic volume. Therefore, a TE system should be scalable to remain applicable as the network evolves. In particular, a TE system should remain functional as the network expands with regard to the number of routers and links, and with respect to the traffic volume. A TE system should have a scalable architecture, should not adversely impair other functions and processes in a network element, and should not consume too much network resources when collecting and distributing state information or when exerting control.
スケーラビリティ：現代公共ネットワークは、ネットワークのサイズと交通量に関して非常に速く成長しています。したがって、TEシステムは、ネットワークが進化するにつれ、適用ままにスケーラブルでなければなりません。ネットワークは、ルータとのリンクの数に関して拡張し、交通量に関してとして、特に、TEシステムは、機能的なままであるべきです。 TEシステムは、悪のネットワーク要素内の他の機能やプロセスを損なうべきではない、スケーラブルなアーキテクチャを持つ必要があり、かつ収集と状態情報を配布するか、コントロールを発揮するときときあまりにも多くのネットワーク・リソースを消費してはなりません。
Stability: Stability is a very important consideration in traffic engineering systems that respond to changes in the state of the network. State-dependent traffic engineering methodologies typically mandate a tradeoff between responsiveness and stability. It is strongly recommended that when tradeoffs are warranted between responsiveness and stability, that the tradeoff should be made in favor of stability (especially in public IP backbone networks).
安定性：安定性は、ネットワークの状態の変化に対応トラフィックエンジニアリング・システムで非常に重要な考慮事項です。状態依存トラフィックエンジニアリング手法は、一般的に応答性と安定性の間のトレードオフを義務付けます。強くトレードオフは、（特にパブリックIPバックボーンネットワークにおける）の安定性に有利に作られるべきであること、トレードオフは、応答性と安定性の間で保証されていたときにすることをお勧めします。
Flexibility: A TE system should be flexible to allow for changes in optimization policy. In particular, a TE system should provide sufficient configuration options so that a network administrator can tailor the TE system to a particular environment. It may also be desirable to have both online and offline TE subsystems which can be independently enabled and disabled. TE systems that are used in multi-class networks should also have options to support class based performance evaluation and optimization.
柔軟性：TEシステムは、最適化ポリシーの変更を可能にするように柔軟であるべきです。ネットワーク管理者は、特定の環境にTEシステムを調整することができるよう具体的には、TEシステムは、十分な設定オプションを提供する必要があります。また、個別に有効と無効にすることができますオンラインとオフラインの両方のTEサブシステムを有することが望ましいです。マルチクラスのネットワークで使用されているTEシステムは、クラスベースの性能評価と最適化をサポートするためのオプションを持っている必要があります。
Visibility: As part of the TE system, mechanisms should exist to collect statistics from the network and to analyze these statistics to determine how well the network is functioning. Derived statistics such as traffic matrices, link utilization, latency, packet loss, and other performance measures of interest which are determined from network measurements can be used as indicators of prevailing network conditions. Other examples of status information which should be observed include existing functional routing information (additionally, in the context of MPLS existing LSP routes), etc.
可視性：TEシステムの一部として、メカニズムがネットワークから統計を収集するために存在する必要があり、ネットワークが機能しているどれだけかを決定するために、これらの統計を分析します。このようなネットワーク測定値から決定されたトラヒックマトリクス、リンク利用率、待ち時間、パケット損失、および関心のある他の性能尺度として導出統計は、優勢なネットワーク状態の指標として用いることができます。 （MPLS既存のLSPの経路の文脈において、付加）機能、ルーティング情報を既存挙げ観察されなければならないステータス情報などの他の例
Simplicity: Generally, a TE system should be as simple as possible. More importantly, the TE system should be relatively easy to use (i.e., clean, convenient, and intuitive user interfaces). Simplicity in user interface does not necessarily imply that the TE system will use naive algorithms. When complex algorithms and internal structures are used, such complexities should be hidden as much as possible from the network administrator through the user interface.
シンプル：一般的に、TEシステムはできるだけシンプルにする必要があります。さらに重要なことは、TEシステムは（すなわち、クリーン便利、且つ直感的なユーザインターフェイス）を使用することは比較的容易であるべきです。ユーザインタフェースの単純さは必ずしもTEシステムは、ナイーブなアルゴリズムを使用することを意味するものではありません。複雑なアルゴリズムと内部構造が使用される場合、そのような複雑さは、ユーザインタフェースを介してネットワーク管理者からできるだけ隠さなければなりません。
Interoperability: Whenever feasible, traffic engineering systems and their components should be developed with open standards based interfaces to allow interoperation with other systems and components.
相互運用性：たび実現可能な、トラフィックエンジニアリング・システムとそのコンポーネントは、他のシステムやコンポーネントとの相互運用を可能にするためのインターフェイスをベースとしたオープンスタンダードに開発されるべきです。
Security: Security is a critical consideration in traffic engineering systems. Such traffic engineering systems typically exert control over certain functional aspects of the network to achieve the desired performance objectives. Therefore, adequate measures must be taken to safeguard the integrity of the traffic engineering system. Adequate measures must also be taken to protect the network from vulnerabilities that originate from security breaches and other impairments within the traffic engineering system.
セキュリティ：セキュリティはトラフィックエンジニアリング・システムの重要な考慮事項です。このようなトラフィックエンジニアリング・システムは、典型的には、所望の性能目標を達成するために、ネットワークの特定の機能面のコントロールを発揮します。そのため、適切な対策は、トラフィックエンジニアリングシステムの完全性を保護するために注意する必要があります。適切な対策は、トラフィックエンジニアリングシステム内のセキュリティ侵害やその他の障害から生じる脆弱性からネットワークを保護するために注意する必要があります。
The remainder of this section will focus on some of the high level functional recommendations for traffic engineering.
このセクションの残りの部分は、トラフィックエンジニアリングのためのハイレベルの機能提言のいくつかに焦点を当てます。
Routing control is a significant aspect of Internet traffic engineering. Routing impacts many of the key performance measures associated with networks, such as throughput, delay, and utilization. Generally, it is very difficult to provide good service quality in a wide area network without effective routing control. A desirable routing system is one that takes traffic characteristics and network constraints into account during route selection while maintaining stability.
コントロールをルーティングは、インターネットトラフィックエンジニアリングの重要な側面です。こうしたスループット、遅延、および使用率などのネットワークに関連した主要なパフォーマンス指標の多くのルーティングの影響。一般的には、効果的なルーティング制御せずに広域ネットワークに優れたサービス品質を提供することは非常に困難です。望ましいルーティングシステムは、安定性を維持しながら、経路選択時アカウントにトラフィック特性及びネットワーク制約をとるものです。
Traditional shortest path first (SPF) interior gateway protocols are based on shortest path algorithms and have limited control capabilities for traffic engineering [RFC-2702, AWD2]. These limitations include :
伝統的な最短パス優先（SPF）内部ゲートウェイプロトコルは、最短パスアルゴリズムに基づいて、トラフィックエンジニアリング[RFC-2702 AWD2]に対する制御能力が限られています。これらの制限は、次のとおりです。
1. The well known issues with pure SPF protocols, which do not take network constraints and traffic characteristics into account during route selection. For example, since IGPs always use the shortest paths (based on administratively assigned link metrics) to forward traffic, load sharing cannot be accomplished among paths of different costs. Using shortest paths to forward traffic conserves network resources, but may cause the following problems: 1) If traffic from a source to a destination exceeds the capacity of a link along the shortest path, the link (hence the shortest path) becomes congested while a longer path between these two nodes may be under-utilized; 2) the shortest paths from different sources can overlap at some links. If the total traffic from the sources exceeds the capacity of any of these links, congestion will occur. Problems can also occur because traffic demand changes over time but network topology and routing configuration cannot be changed as rapidly. This causes the network topology and routing configuration to become sub-optimal over time, which may result in persistent congestion problems.
1.ルート選択の際に考慮にネットワークの制約とトラフィック特性を取ることはありません純粋なSPFプロトコル、とよく知られている問題。 IGPは常にトラフィックを転送する（行政上割り当てられたリンクメトリックに基づいて）最短経路を使用するので、例えば、負荷分散は、異なるコストのパスの間に達成することができません。トラフィックを転送する最短経路を使用して、ネットワークリソースを節約するが、次のような問題が発生することがあり：ソースから宛先へのトラフィックは、最短経路に沿ったリンクの容量を超える場合ながら1）、リンク（したがって最短経路）が混雑しますこれら2つのノード間のより長い経路がアンダー利用することができます。 2）異なるソースからの最短経路はいくつかのリンクで重なり合うことができます。ソースからの総トラフィックは、これらのリンクのいずれかの容量を超えた場合、輻輳が発生します。時間が、ネットワークトポロジとルーティング設定上のトラフィック需要の変化が急激として変更することができないので、問題が発生することもあります。これは、ネットワークトポロジーおよびルーティング構成が永続的輻輳問題をもたらす可能性が、経時的に準最適になるようにします。
2. The Equal-Cost Multi-Path (ECMP) capability of SPF IGPs supports sharing of traffic among equal cost paths between two nodes. However, ECMP attempts to divide the traffic as equally as possible among the equal cost shortest paths. Generally, ECMP does not support configurable load sharing ratios among equal cost paths. The result is that one of the paths may carry significantly more traffic than other paths because it may also carry traffic from other sources. This situation can result in congestion along the path that carries more traffic.
2. SPFのIGPの等価コストマルチパス（ECMP）機能は、2つのノード間の等コストパスの間でトラフィックの共有をサポートします。しかし、ECMPは等しいコスト最短経路のうちできるだけ均等トラフィックを分割することを試みます。一般に、ECMPは、等コスト・パス間で設定可能な負荷分担率をサポートしていません。結果はまた、他のソースからのトラフィックを運ぶことができるので、パスの一方が他の経路よりも有意に多くのトラフィックを搬送することができるということです。この状況は、より多くのトラフィックを運ぶ経路に沿って、輻輳が発生することができます。
3. Modifying IGP metrics to control traffic routing tends to have network-wide effect. Consequently, undesirable and unanticipated traffic shifts can be triggered as a result. Recent work described in Section 8.0 may be capable of better control [FT00, FT01].
3.トラフィックルーティングを制御するためのIGPメトリックを変更すると、ネットワーク全体の効果を持っている傾向があります。したがって、望ましくないと予期せぬトラフィックのシフトは、結果としてトリガすることができます。セクション8.0で説明最近の研究は、[FT00、FT01]より良好に制御することが可能であり得ます。
Because of these limitations, new capabilities are needed to enhance the routing function in IP networks. Some of these capabilities have been described elsewhere and are summarized below.
これらの制限のため、新機能は、IPネットワーク内のルーティング機能を強化するために必要とされています。これらの機能のいくつかは他の場所に記載されていると、以下のように要約されています。
Constraint-based routing is desirable to evolve the routing architecture of IP networks, especially public IP backbones with complex topologies [RFC-2702]. Constraint-based routing computes routes to fulfill requirements subject to constraints. Constraints may include bandwidth, hop count, delay, and administrative policy instruments such as resource class attributes [RFC-2702, RFC-2386]. This makes it possible to select routes that satisfy a given set of requirements subject to network and administrative policy constraints. Routes computed through constraint-based routing are not necessarily the shortest paths. Constraint-based routing works best with path oriented technologies that support explicit routing, such as MPLS.
制約ベースのルーティングは、複雑なトポロジ[RFC-2702]と特にパブリックIPバックボーンIPネットワークのルーティングアーキテクチャを発展させることが望ましいです。制約ベースのルーティングは、制約を受ける要件を満たすために経路を計算します。制約は、帯域幅、ホップ数、遅延、および、そのようなリソースクラス属性[RFC-2702、RFC-2386]などの管理政策手段を備えることができます。これは、ネットワークおよび管理ポリシーの制約を受ける要件の特定のセットを満たすルートを選択することが可能になります。制約ベースのルーティングを介して計算されたルートは、必ずしも最短経路ではありません。制約ベースのルーティングは、MPLSなどの明示的なルーティングをサポートし、パス指向技術、に最適です。
Constraint-based routing can also be used as a way to redistribute traffic onto the infrastructure (even for best effort traffic). For example, if the bandwidth requirements for path selection and reservable bandwidth attributes of network links are appropriately defined and configured, then congestion problems caused by uneven traffic distribution may be avoided or reduced. In this way, the performance and efficiency of the network can be improved.
制約ベースのルーティングは、（さえベストエフォートトラフィックのための）インフラストラクチャ上のトラフィックを再分配するための方法として使用することができます。経路選択及びネットワークリンクの予約可能帯域幅属性の帯域幅要件が適切に定義され、構成されている場合、例えば、その後、不均一なトラフィック分布に起因する輻輳問題を回避又は低減することができます。このように、ネットワークの性能及び効率を向上させることができます。
A number of enhancements are needed to conventional link state IGPs, such as OSPF and IS-IS, to allow them to distribute additional state information required for constraint-based routing. These extensions to OSPF were described in [KATZ] and to IS-IS in [SMIT]. Essentially, these enhancements require the propagation of additional information in link state advertisements. Specifically, in addition to normal link-state information, an enhanced IGP is required to propagate topology state information needed for constraint-based routing. Some of the additional topology state information include link attributes such as reservable bandwidth and link resource class attribute (an administratively specified property of the link). The resource class attribute concept was defined in [RFC-2702]. The additional topology state information is carried in new TLVs and sub-TLVs in IS-IS, or in the Opaque LSA in OSPF [SMIT, KATZ].
拡張の数は、それらを制約ベースのルーティングに必要な追加の状態情報を配信することを可能にするために、OSPFのような従来のリンク状態のIGPに必要とIS-ISれます。 [SMIT]でOSPFに対するこれらの拡張機能は、[KATZ]にし、IS-ISに説明しました。基本的に、これらの拡張機能は、リンクステートアドバタイズメントに追加情報の伝播を必要としています。具体的には、通常のリンク状態情報に加えて、拡張IGPは、制約ベースのルーティングに必要なトポロジ状態情報を伝搬するために必要とされます。追加のトポロジ状態情報の一部は、予約可能帯域幅とリンクリソースクラス属性（リンクの管理上、指定されたプロパティ）としてリンク属性が含まれます。リソースクラス属性の概念は、[RFC-2702]で定義されていました。追加のトポロジ状態情報が新しいのTLV及びIS-ISサブTLVの中に、またはOSPFにおけるオペークLSA [SMIT、KATZ]で運ばれます。
An enhanced link-state IGP may flood information more frequently than a normal IGP. This is because even without changes in topology, changes in reservable bandwidth or link affinity can trigger the enhanced IGP to initiate flooding. A tradeoff is typically required between the timeliness of the information flooded and the flooding frequency to avoid excessive consumption of link bandwidth and computational resources, and more importantly, to avoid instability.
強化されたリンクステートIGPは、通常のIGPよりも頻繁に情報をあふれさせることがあります。でも、トポロジの変更なしに、予約可能帯域幅やリンクの親和性の変化は、洪水を開始するために拡張IGPを誘発することができるからです。トレードオフは、一般的に不安定性を回避するために、もっと重要なリンク帯域幅と計算資源の過剰消費を避けるために、浸水情報の適時や洪水の頻度との間で必要とされます。
In a TE system, it is also desirable for the routing subsystem to make the load splitting ratio among multiple paths (with equal cost or different cost) configurable. This capability gives network administrators more flexibility in the control of traffic distribution across the network. It can be very useful for avoiding/relieving congestion in certain situations. Examples can be found in [XIAO].
TEシステムでは、ルーティングサブシステムは、構成（等価コストまたは異なるコストを有する）複数のパス間の負荷分割比を作るためにも望ましいです。この機能により、ネットワーク管理者はネットワーク全体のトラフィック分布の制御でより多くの柔軟性を提供します。これは、特定の状況での混雑を緩和/回避するために非常に便利です。例としては、[XIAO]に見出すことができます。
The routing system should also have the capability to control the routes of subsets of traffic without affecting the routes of other traffic if sufficient resources exist for this purpose. This capability allows a more refined control over the distribution of traffic across the network. For example, the ability to move traffic from a source to a destination away from its original path to another path (without affecting other traffic paths) allows traffic to be moved from resource-poor network segments to resource-rich segments. Path oriented technologies such as MPLS inherently support this capability as discussed in [AWD2].
ルーティングシステムはまた、十分なリソースが、この目的のために存在する場合は、他のトラフィックのルーティングに影響を与えることなく、トラフィックのサブセットのルートを制御する機能を持っている必要があります。この機能は、ネットワーク上のトラフィックの分布をより洗練された制御することができます。例えば、（他のトラフィックの経路に影響を与えることなく）別のパスに離れて元の経路から送信元から宛先へトラフィックを移動させる能力は、トラフィックがリソースリッチセグメントに資源の乏しいネットワークセグメントから移動することを可能にします。 [AWD2]で述べたようなMPLSなどの経路指向技術は本質的に、この機能をサポートしています。
Additionally, the routing subsystem should be able to select different paths for different classes of traffic (or for different traffic behavior aggregates) if the network supports multiple classes of service (different behavior aggregates).
ネットワークサービス（異なる振る舞い凝集体）の複数のクラスをサポートしている場合さらに、ルーティングサブシステムは、（または異なる交通行動の集合体のための）トラフィックの異なるクラスごとに異なるパスを選択することができるはずです。
Traffic mapping pertains to the assignment of traffic workload onto pre-established paths to meet certain requirements. Thus, while constraint-based routing deals with path selection, traffic mapping deals with the assignment of traffic to established paths which may have been selected by constraint-based routing or by some other means. Traffic mapping can be performed by time-dependent or state-dependent mechanisms, as described in Section 5.1.
トラフィックマッピングは、特定の要件を満たすように予め確立経路上のトラフィックの負荷の割り当てに関する。したがって、経路選択、制約ベースのルーティングによって、または他の何らかの手段によって選択されている可能性が確立されたパスにトラフィックの割り当てとトラフィックマッピングながら予約制約ベースのルーティングディールします。セクション5.1で説明したように、トラフィックのマッピングは、時間依存性または状態依存性機構によって行うことができます。
An important aspect of the traffic mapping function is the ability to establish multiple paths between an originating node and a destination node, and the capability to distribute the traffic between the two nodes across the paths according to some policies. A pre-condition for this scheme is the existence of flexible mechanisms to partition traffic and then assign the traffic partitions onto the parallel paths. This requirement was noted in [RFC-2702]. When traffic is assigned to multiple parallel paths, it is recommended that special care should be taken to ensure proper ordering of packets belonging to the same application (or micro-flow) at the destination node of the parallel paths.
トラフィックマッピング機能の重要な側面は、複数の発信元ノードと宛先ノードの間の経路、及びいくつかのポリシーに従ってパスを横切って2つのノード間のトラフィックを分散させる能力を確立する能力です。このスキームのための前提条件は、トラフィックを分割した後、並列経路上のトラフィックのパーティションを割り当てるための柔軟なメカニズムの存在です。この要件は、[RFC-2702]で述べました。トラフィックが複数の並列パスに割り当てられている場合には、特別な注意が並列パスの宛先ノードで同じアプリケーション（またはマイクロフロー）に属するパケットの適切な順序を保証するために注意しなければならないことが推奨されます。
As a general rule, mechanisms that perform the traffic mapping functions should aim to map the traffic onto the network infrastructure to minimize congestion. If the total traffic load cannot be accommodated, or if the routing and mapping functions cannot react fast enough to changing traffic conditions, then a traffic mapping system may rely on short time scale congestion control mechanisms (such as queue management, scheduling, etc.) to mitigate congestion. Thus, mechanisms that perform the traffic mapping functions should complement existing congestion control mechanisms. In an operational network, it is generally desirable to map the traffic onto the infrastructure such that intra-class and inter-class resource contention are minimized.
原則として、トラフィックマッピング機能を実行するメカニズムは、輻輳を最小限にするために、ネットワークインフラストラクチャ上にトラフィックをマッピングすることを目指すべきです。総トラフィック負荷を収容することができない場合、ルーティングおよびマッピング機能は交通状況の変化に十分に速く反応することができない場合、または、トラフィック・マッピング・システムは、（例えば、待ち行列管理、スケジューリング、など）短い時間スケールの輻輳制御メカニズムに依拠することができます混雑を緩和します。このように、交通マッピング機能を実行するメカニズムは、既存の輻輳制御メカニズムを補完する必要があります。運用ネットワークでは、クラス内およびクラス間のリソースの競合が最小化されるように、インフラストラクチャ上のトラフィックをマッピングすることが一般的に望ましいです。
When traffic mapping techniques that depend on dynamic state feedback (e.g., MATE and such like) are used, special care must be taken to guarantee network stability.
動的状態フィードバック（例えば、MATEなどなど）に依存するトラフィックマッピング技術が使用される場合、特別な注意がネットワークの安定性を保証するために注意しなければなりません。
The importance of measurement in traffic engineering has been discussed throughout this document. Mechanisms should be provided to measure and collect statistics from the network to support the traffic engineering function. Additional capabilities may be needed to help in the analysis of the statistics. The actions of these mechanisms should not adversely affect the accuracy and integrity of the statistics collected. The mechanisms for statistical data acquisition should also be able to scale as the network evolves.
トラフィックエンジニアリングでの測定の重要性は、この文書全体で議論されています。メカニズムは、トラフィックエンジニアリング機能をサポートするために測定し、ネットワークからの統計情報を収集するために提供されるべきです。追加機能は、統計の分析で助けるために必要とすることができます。これらのメカニズムの行動に悪影響を収集した統計情報の正確性および完全性に影響を与えるべきではありません。統計データ収集のためのメカニズムは、ネットワークが進化として拡張することができなければなりません。
Traffic statistics may be classified according to long-term or short-term time scales. Long-term time scale traffic statistics are very useful for traffic engineering. Long-term time scale traffic statistics may capture or reflect periodicity in network workload (such as hourly, daily, and weekly variations in traffic profiles) as well as traffic trends. Aspects of the monitored traffic statistics may also depict class of service characteristics for a network supporting multiple classes of service. Analysis of the long-term traffic statistics MAY yield secondary statistics such as busy hour characteristics, traffic growth patterns, persistent congestion problems, hot-spot, and imbalances in link utilization caused by routing anomalies.
トラフィック統計は、長期または短期の時間スケールに応じて分類することができます。長期的時間スケールのトラフィックの統計情報は、トラフィックエンジニアリングのために非常に有用です。長期的時間スケールのトラフィックの統計情報をキャプチャするかだけでなく、トラフィックの傾向（例えば毎時、毎日、毎週トラフィックプロファイルの変動など）のネットワーク・ワークロードでの周期性を反映することができます。監視対象のトラフィックの統計情報の態様は、複数のサービスクラスをサポートするネットワークのためのサービス特性のクラスを示すことができます。長期的なトラフィック統計情報の分析は、このような異常をルーティングによって引き起こさ忙しい時間の特性、トラフィックの成長パターン、持続的な輻輳の問題、ホットスポット、およびリンク利用率の不均衡などの二次統計をもたらす可能性があります。
A mechanism for constructing traffic matrices for both long-term and short-term traffic statistics should be in place. In multi-service IP networks, the traffic matrices may be constructed for different service classes. Each element of a traffic matrix represents a statistic of traffic flow between a pair of abstract nodes. An abstract node may represent a router, a collection of routers, or a site in a VPN.
長期および短期の両方のトラフィック統計のトラフィック行列を構築するためのメカニズムが場所にする必要があります。マルチサービスIPネットワークでは、トラフィック行列は異なるサービスクラスのために構築することができます。トラフィック行列の各要素は、抽象ノードの対の間のトラフィックフローの統計を表します。抽象ノードはルータ、ルータのコレクション、またはVPNでサイトを表すことができます。
Measured traffic statistics should provide reasonable and reliable indicators of the current state of the network on the short-term scale. Some short term traffic statistics may reflect link utilization and link congestion status. Examples of congestion indicators include excessive packet delay, packet loss, and high resource utilization. Examples of mechanisms for distributing this kind of information include SNMP, probing techniques, FTP, IGP link state advertisements, etc.
測定されたトラフィックの統計情報は、短期的な規模でのネットワークの現在の状態の合理的かつ信頼性の高い指標を提供する必要があります。いくつかの短期的なトラフィックの統計情報は、リンクの利用率とリンクの輻輳状態を反映することができます。渋滞指標としては、例えば、過剰なパケット遅延、パケット損失、および高いリソース利用率を含みます。この種の情報を配布するためのメカニズムの例には、SNMP、プロービング技術、FTP、IGPリンク状態広告を含みます
Network survivability refers to the capability of a network to maintain service continuity in the presence of faults. This can be accomplished by promptly recovering from network impairments and maintaining the required QoS for existing services after recovery. Survivability has become an issue of great concern within the Internet community due to the increasing demands to carry mission critical traffic, real-time traffic, and other high priority traffic over the Internet. Survivability can be addressed at the device level by developing network elements that are more reliable; and at the network level by incorporating redundancy into the architecture, design, and operation of networks. It is recommended that a philosophy of robustness and survivability should be adopted in the architecture, design, and operation of traffic engineering that control IP networks (especially public IP networks). Because different contexts may demand different levels of survivability, the mechanisms developed to support network survivability should be flexible so that they can be tailored to different needs.
ネットワークサバイバビリティは、障害の存在下で、サービスの継続性を維持するために、ネットワークの機能を指します。これは、速やかにネットワーク障害からの回復と復旧後に既存のサービスのために必要なQoSを維持することによって達成することができます。耐障害性は、インターネット上でのミッションクリティカルなトラフィック、リアルタイムトラフィック、および他の優先度の高いトラフィックを運ぶのに伴う需要の増加にインターネットコミュニティの中で大きな懸念の課題となっています。生存性は、より信頼性のあるネットワーク要素を開発することによって、デバイスレベルで対処することができます。およびネットワークのアーキテクチャ、設計、および動作中に冗長性を組み込むことにより、ネットワークレベルで。堅牢性と生存率の哲学は、IPネットワーク（特に公衆IP網）を制御トラフィックエンジニアリングのアーキテクチャ、設計、および操作に採用することをお勧めします。異なるコンテキストが生存性の異なるレベルを要求することができるので、彼らは別のニーズに合わせて調整することができるように、ネットワークの存続を支援するために開発されたメカニズムは柔軟であるべきです。
Failure protection and restoration capabilities have become available from multiple layers as network technologies have continued to improve. At the bottom of the layered stack, optical networks are now capable of providing dynamic ring and mesh restoration functionality at the wavelength level as well as traditional protection functionality. At the SONET/SDH layer survivability capability is provided with Automatic Protection Switching (APS) as well as self-healing ring and mesh architectures. Similar functionality is provided by layer 2 technologies such as ATM (generally with slower mean restoration times). Rerouting is traditionally used at the IP layer to restore service following link and node outages. Rerouting at the IP layer occurs after a period of routing convergence which may require seconds to minutes to complete. Some new developments in the MPLS context make it possible to achieve recovery at the IP layer prior to convergence [SHAR].
ネットワーク技術は引き続き改善してきたように、障害の保護と復旧機能は、複数の層から利用可能となっています。層状スタックの底部に、光ネットワークは今、波長レベルでの動的リングとメッシュ回復機能、ならびに従来の保護機能を提供することができます。で、SONET / SDHレイヤの存続能力は、自動保護スイッチング（APS）と同様に自己修復リングおよびメッシュアーキテクチャを備えています。同様の機能は、（一般的に遅い平均復旧時間を有する）、ATMなどのレイヤ2つのテクノロジによって提供されます。再ルーティングは、伝統的に、リンクやノードの停止次のサービスを復元するために、IP層で使用されています。 IP層での再ルーティングは、完了するのに数秒〜数分を必要とするかもしれ収束をルーティングする期間の後に起こります。 MPLSの文脈でいくつかの新しい開発は[SHAR]収束する前にIP層での回復を達成することを可能にします。
To support advanced survivability requirements, path-oriented technologies such a MPLS can be used to enhance the survivability of IP networks in a potentially cost effective manner. The advantages of path oriented technologies such as MPLS for IP restoration becomes even more evident when class based protection and restoration capabilities are required.
、パス指向技術を高度なサバイバビリティ要件をサポートするために、このようなMPLSは、潜在的に効果的な方法をコストのIPネットワークの生存性を向上させるために使用することができます。クラスベースの保護と回復能力が必要な場合にIPの修復のためのMPLSなどの経路指向技術の利点は一層明白になります。
Recently, a common suite of control plane protocols has been proposed for both MPLS and optical transport networks under the acronym Multi-protocol Lambda Switching [AWD1]. This new paradigm of Multi-protocol Lambda Switching will support even more sophisticated mesh restoration capabilities at the optical layer for the emerging IP over WDM network architectures.
最近では、制御プレーンプロトコルの一般的なスイートは、[AWD1】スイッチングマルチプロトコルラムダ略語下MPLSおよび光トランスポートネットワークの両方のために提案されています。マルチプロトコルラムダスイッチングのこの新しいパラダイムは、WDMネットワークアーキテクチャの上に新たなIPのための光学層でも、より洗練されたメッシュの復元機能をサポートします。
Another important aspect regarding multi-layer survivability is that technologies at different layers provide protection and restoration capabilities at different temporal granularities (in terms of time scales) and at different bandwidth granularity (from packet-level to wavelength level). Protection and restoration capabilities can also be sensitive to different service classes and different network utility models.
多層生存に関する別の重要な局面は、異なる層における技術は（パケットレベルから波長レベル）（時間尺度に関して）異なる時間粒度で、異なる帯域単位での保護と回復機能を提供することです。保護と復旧機能も異なるサービスクラスと異なるネットワーク・ユーティリティ・モデルに敏感であることができます。
The impact of service outages varies significantly for different service classes depending upon the effective duration of the outage. The duration of an outage can vary from milliseconds (with minor service impact) to seconds (with possible call drops for IP telephony and session time-outs for connection oriented transactions) to minutes and hours (with potentially considerable social and business impact).
サービス停止の影響は、停止の有効期間に応じて異なるサービスクラスに対して大きく変化します。 （可能な通話が接続指向の取引のためにIPテレフォニーおよびセッションタイムアウトのために低下すると）停止の期間は、（潜在的にかなりの社会的およびビジネスインパクトで）分と時間を秒に（マイナー、サービスに影響を持つ）ミリ秒ごとに異なることができます。
Coordinating different protection and restoration capabilities across multiple layers in a cohesive manner to ensure network survivability is maintained at reasonable cost is a challenging task. Protection and restoration coordination across layers may not always be feasible, because networks at different layers may belong to different administrative domains.
合理的なコストで維持されているネットワークの存続を確実にするために凝集方法で複数の層を横切る異なる保護と回復能力を調整することは困難な作業です。異なる層でのネットワークが異なる管理ドメインに属している可能性があるため、層全体の保護と復旧の調整は常に、実行可能ではないかもしれません。
The following paragraphs present some of the general recommendations for protection and restoration coordination.
次の段落では、保護と修復の調整のための一般的な推奨事項のいくつかを提示します。
- Protection and restoration capabilities from different layers should be coordinated whenever feasible and appropriate to provide network survivability in a flexible and cost effective manner. Minimization of function duplication across layers is one way to achieve the coordination. Escalation of alarms and other fault indicators from lower to higher layers may also be performed in a coordinated manner. A temporal order of restoration trigger timing at different layers is another way to coordinate multi-layer protection/restoration.
- 柔軟かつ費用効果的な方法でネットワークの生存を提供するために、いつでも実行可能かつ適切な保護と異なる層からの復旧機能が調整されるべきです。レイヤー全体の機能の重複の最小化はコーディネートを達成するための一つの方法です。下位から上位レイヤにアラームや他の障害インジケータのエスカレーションも協調して実行することができます。異なる層における復元トリガタイミングの時間的な順序は、多層保護/復元を調整する別の方法です。
- Spare capacity at higher layers is often regarded as working traffic at lower layers. Placing protection/restoration functions in many layers may increase redundancy and robustness, but it should not result in significant and avoidable inefficiencies in network resource utilization.
- 上位層の空き容量は、多くの場合、下位層でトラフィックを作業とみなされています。多くの層で保護/復元機能を配置することで、冗長性と堅牢性を高めるかもしれないが、それは、ネットワークリソースの利用率に重大かつ回避可能な非効率になってはなりません。
- It is generally desirable to have protection and restoration schemes that are bandwidth efficient.
- 一般的に帯域幅の効率的な保護と回復スキームを有することが望ましいです。
- Failure notification throughout the network should be timely and reliable.
- ネットワーク全体の障害通知は、タイムリーかつ信頼できるものでなければなりません。
- Alarms and other fault monitoring and reporting capabilities should be provided at appropriate layers.
- アラームおよび他の障害監視とレポート作成機能は、適切なレイヤで提供されるべきです。
MPLS is an important emerging technology that enhances IP networks in terms of features, capabilities, and services. Because MPLS is path-oriented, it can potentially provide faster and more predictable protection and restoration capabilities than conventional hop by hop routed IP systems. This subsection describes some of the basic aspects and recommendations for MPLS networks regarding protection and restoration. See [SHAR] for a more comprehensive discussion on MPLS based recovery.
MPLSは、機能、能力、およびサービスの面で、IPネットワークを強化する重要な新技術です。 MPLSパス指向であるため、それが潜在的にホップすることにより、従来のホップよりも速く、より予測可能な保護と回復機能を提供できるIPシステムをルーティングされました。ここでは、保護と回復に関するMPLSネットワークのための基本的な側面と推奨事項について説明します。 MPLSベースの回復のより包括的な議論については[SHAR]を参照してください。
Protection types for MPLS networks can be categorized as link protection, node protection, path protection, and segment protection.
MPLSネットワークの保護タイプは、リンク保護、ノード保護、パスプロテクション、およびセグメント保護として分類することができます。
- Link Protection: The objective for link protection is to protect an LSP from a given link failure. Under link protection, the path of the protection or backup LSP (the secondary LSP) is disjoint from the path of the working or operational LSP at the particular link over which protection is required. When the protected link fails, traffic on the working LSP is switched over to the protection LSP at the head-end of the failed link. This is a local repair method which can be fast. It might be more appropriate in situations where some network elements along a given path are less reliable than others.
- リンク保護：リンク保護の目的は、与えられたリンク障害からのLSPを保護することです。リンク保護の下で、保護またはバックアップLSP（二次LSP）の経路は、保護が要求される上に、特定のリンクにおける作業または動作LSPの経路からばらばらです。保護されたリンクに障害が発生した場合、作業LSP上のトラフィックが失敗したリンクのヘッドエンドで保護LSPに切り替えています。これは、高速であることができますローカルの修復方法です。これは、指定されたパスに沿っていくつかのネットワーク要素が他よりも信頼性が低い状況では、より適切な場合があります。
- Node Protection: The objective of LSP node protection is to protect an LSP from a given node failure. Under node protection, the path of the protection LSP is disjoint from the path of the working LSP at the particular node to be protected. The secondary path is also disjoint from the primary path at all links associated with the node to be protected. When the node fails, traffic on the working LSP is switched over to the protection LSP at the upstream LSR directly connected to the failed node.
- ノードの保護：LSPノード保護の目的は、与えられたノード障害からのLSPを保護することです。ノード保護下、保護LSPの経路は、保護されるべき特定のノードでの作動LSPの経路からばらばらです。二次経路はまた、保護されるべきノードに関連するすべてのリンクにプライマリパスからばらばらです。ノードに障害が発生した場合、作業LSP上のトラフィックが直接障害が発生したノードに接続され、上流LSRで保護LSPに切り替えています。
- Path Protection: The goal of LSP path protection is to protect an LSP from failure at any point along its routed path. Under path protection, the path of the protection LSP is completely disjoint from the path of the working LSP. The advantage of path protection is that the backup LSP protects the working LSP from all possible link and node failures along the path, except for failures that might occur at the ingress and egress LSRs, or for correlated failures that might impact both working and backup paths simultaneously. Additionally, since the path selection is end-to-end, path protection might be more efficient in terms of resource usage than link or node protection. However, path protection may be slower than link and node protection in general.
- パス保護：LSPパス保護の目標は、そのルーティングパスに沿った任意の点での障害からのLSPを保護することです。パス保護の下では、保護LSPのパスは、作業LSPのパスから完全にばらばらです。パスプロテクションの利点は、バックアップLSPの経路に沿って、入口で発生する可能性がある障害と出口LSRsを除いて、または作業及び予備パスの両方に影響を与える可能性がある相関障害のすべての可能なリンクとノードの障害から作業LSPを保護することです同時に。パスの選択は、エンド・ツー・エンドであるため、また、パスの保護は、リンクまたはノード保護よりもリソース使用率の点でより効率的かもしれません。しかし、パス保護は一般的には、リンクおよびノード保護よりも遅くなることがあります。
- Segment Protection: An MPLS domain may be partitioned into multiple protection domains whereby a failure in a protection domain is rectified within that domain. In cases where an LSP traverses multiple protection domains, a protection mechanism within a domain only needs to protect the segment of the LSP that lies within the domain. Segment protection will generally be faster than path protection because recovery generally occurs closer to the fault.
- セグメント保護：保護ドメイン内の故障は、そのドメイン内で整流されるMPLSドメインが複数の保護ドメインに分割することができます。 LSPは、複数の保護ドメインを横断する場合には、ドメイン内の保護機構は、ドメイン内にあるLSPのセグメントを保護する必要があります。回復は、一般的に、障害に近い発生するため、セグメント保護は一般的にパス保護よりも速くなります。
Another issue to consider is the concept of protection options. The protection option uses the notation m:n protection, where m is the number of protection LSPs used to protect n working LSPs. Feasible protection options follow.
考慮すべきもう一つの問題は、保護オプションの概念です。 Mは、nワーキングLSPを保護するために使用される保護LSPの数であるN保護：保護オプションは、表記Mを使用します。実現可能な保護オプションは以下の通り。
- 1:1: one working LSP is protected/restored by one protection LSP.
- 1：1：1働くLSPは、一つの保護LSPによって復元/保護されています。
- 1:n: one protection LSP is used to protect/restore n working LSPs.
- 1：N：1つの保護LSPは/保護、復元nは作業のLSPするために使用されます。
- n:1: one working LSP is protected/restored by n protection LSPs, possibly with configurable load splitting ratio. When more than one protection LSP is used, it may be desirable to share the traffic across the protection LSPs when the working LSP fails to satisfy the bandwidth requirement of the traffic trunk associated with the working LSP. This may be especially useful when it is not feasible to find one path that can satisfy the bandwidth requirement of the primary LSP.
- nは1：1ワーキングLSPは、おそらく設定負荷分割比で、N保護のLSPによって回復/保護されています。複数の保護LSPを使用した場合、働くLSPが働くLSPに関連するトラフィックトランクの帯域幅要件を満たすために失敗したときに保護LSPの間でトラフィックを共有することが望ましい場合があります。主LSPの帯域幅要件を満たすことができる一つのパスを見つけることは不可能である場合に特に有用である可能性があります。
- 1+1: traffic is sent concurrently on both the working LSP and the protection LSP. In this case, the egress LSR selects one of the two LSPs based on a local traffic integrity decision process, which compares the traffic received from both the working and the protection LSP and identifies discrepancies. It is unlikely that this option would be used extensively in IP networks due to its resource utilization inefficiency. However, if bandwidth becomes plentiful and cheap, then this option might become quite viable and attractive in IP networks.
- 1 + 1：トラフィックがワーキングLSPと保護LSPの両方に同時に送信されます。この場合、出口LSRは、現用と予備LSPの両方から受信したトラフィックを比較し、不一致を識別するローカルトラフィック整合性判定処理、に基づいて、2つのLSPのいずれかを選択します。このオプションはその資源利用効率の悪さに起因するIPネットワークで広く使用されることはほとんどありません。帯域幅が豊富で安価になった場合ただし、このオプションは、IPネットワークでは非常に実行可能な、魅力的になるかもしれません。
This section provides an overview of the traffic engineering features and recommendations that are specifically pertinent to Differentiated Services (Diffserv) [RFC-2475] capable IP networks.
このセクションでは、[RFC-2475]可能なIPネットワーク差別化サービス（Diffservの）に特異的に関連しているトラフィックエンジニアリング機能と推奨事項の概要を提供します。
Increasing requirements to support multiple classes of traffic, such as best effort and mission critical data, in the Internet calls for IP networks to differentiate traffic according to some criteria, and to accord preferential treatment to certain types of traffic. Large numbers of flows can be aggregated into a few behavior aggregates based on some criteria in terms of common performance requirements in terms of packet loss ratio, delay, and jitter; or in terms of common fields within the IP packet headers.
IPネットワーク用のインターネット通話中に、いくつかの基準に従ってトラフィックを区別するために、および特定の種類のトラフィックに優先的に処理をアコードするために、最善の努力と、ミッションクリティカルなデータとして、トラフィックの複数のクラスをサポートするための要件を増やします。流れの多数は、パケット損失率、遅延、およびジッタの点で共通の性能要件の点でいくつかの基準に基づいていくつかの動作凝集体に集約することができます。またはIPパケットのヘッダ内の共通フィールドの観点インチ
As Diffserv evolves and becomes deployed in operational networks, traffic engineering will be critical to ensuring that SLAs defined within a given Diffserv service model are met. Classes of service (CoS) can be supported in a Diffserv environment by concatenating per-hop behaviors (PHBs) along the routing path, using service provisioning mechanisms, and by appropriately configuring edge functionality such as traffic classification, marking, policing, and shaping. PHB is the forwarding behavior that a packet receives at a DS node (a Diffserv-compliant node). This is accomplished by means of buffer management and packet scheduling mechanisms. In this context, packets belonging to a class are those that are members of a corresponding ordering aggregate.
Diffservのが進化し、運用ネットワークに展開につれて、トラフィックエンジニアリングは、与えられたDiffservサービスモデル内で定義されたSLAを満たしていることを確実にするために重要となります。サービス（COS）のクラスは、ルーティングパスに沿って行動（のPHB）ホップごと連結するサービスプロビジョニングメカニズムを使用して、Diffservの環境でサポートされ、適切にそのようなトラフィック分類、マーキング、ポリシング、およびシェーピングとしてエッジ機能を設定することによってすることができます。 PHBは、パケットがDSノード（Diffservの対応ノード）に受信転送動作です。これは、バッファ管理およびパケットスケジューリングメカニズムによって達成されます。この文脈では、クラスに属するパケットは、対応する順序集合体のメンバーであるものです。
Traffic engineering can be used as a compliment to Diffserv mechanisms to improve utilization of network resources, but not as a necessary element in general. When traffic engineering is used, it can be operated on an aggregated basis across all service classes [RFC-3270] or on a per service class basis. The former is used to provide better distribution of the aggregate traffic load over the network resources. (See [RFC-3270] for detailed mechanisms to support aggregate traffic engineering.) The latter case is discussed below since it is specific to the Diffserv environment, with so called Diffserv-aware traffic engineering [DIFF_TE].
トラフィックエンジニアリングはなく、一般的に必要な要素として、ネットワークリソースの利用率を向上させるためのDiffservメカニズムに賛辞として使用することができます。トラフィックエンジニアリングを使用した場合、それはすべてのサービスクラス[RFC-3270]全体で集計単位またはサービスクラスごとに操作することができます。前者はネットワークリソースを集約トラフィック負荷のより良い分布を提供するために使用されます。 （詳細なメカニズムは集約トラフィックエンジニアリングをサポートする[RFC-3270]を参照）。後者の場合は、[DIFF_TE】いわゆるdiffserv対応トラフィックエンジニアリングと、それはDiffservの環境に固有であるので、以下に説明します。
For some Diffserv networks, it may be desirable to control the performance of some service classes by enforcing certain relationships between the traffic workload contributed by each service class and the amount of network resources allocated or provisioned for that service class. Such relationships between demand and resource allocation can be enforced using a combination of, for example: (1) traffic engineering mechanisms on a per service class basis that enforce the desired relationship between the amount of traffic contributed by a given service class and the resources allocated to that class, and (2) mechanisms that dynamically adjust the resources allocated to a given service class to relate to the amount of traffic contributed by that service class.
いくつかのDiffservネットワークの場合には、各サービス・クラスとそのサービスクラスに割り当てるか、プロビジョニングネットワークリソースの量によって寄与トラフィックの負荷との間に一定の関係を強制することによって、いくつかのサービス・クラスの性能を制御することが望ましい場合があります。与えられたサービスクラスによって寄与トラフィックの量と割り当てられたリソースとの間の所望の関係を強制サービスクラスごとに（1）トラフィックエンジニアリング機構：例えば需要とリソース割り当てとの間のそのような関係の組み合わせを使用して実施することができます。動的にそのサービスクラスによって寄与トラフィックの量に関連する所定のサービス・クラスに割り当てられたリソースを調整メカニズムそのクラス、および（2）。
It may also be desirable to limit the performance impact of high priority traffic on relatively low priority traffic. This can be achieved by, for example, controlling the percentage of high priority traffic that is routed through a given link. Another way to accomplish this is to increase link capacities appropriately so that lower priority traffic can still enjoy adequate service quality. When the ratio of traffic workload contributed by different service classes vary significantly from router to router, it may not suffice to rely exclusively on conventional IGP routing protocols or on traffic engineering mechanisms that are insensitive to different service classes. Instead, it may be desirable to perform traffic engineering, especially routing control and mapping functions, on a per service class basis. One way to accomplish this in a domain that supports both MPLS and Diffserv is to define class specific LSPs and to map traffic from each class onto one or more LSPs that correspond to that service class. An LSP corresponding to a given service class can then be routed and protected/restored in a class dependent manner, according to specific policies.
また、比較的低い優先度のトラフィックに優先度の高いトラフィックのパフォーマンスへの影響を制限することが望ましい場合があります。これは、例えば、与えられたリンクを介してルーティングされ、優先度の高いトラフィックの割合を制御する、ことによって達成することができます。これを達成するもう一つの方法は、優先度の低いトラフィックは、まだ十分なサービス品質を楽しむことができるように適切にリンク容量を増加させることです。異なるサービスクラスによって寄与トラフィックワークロードの比率がルータにルータから大きく変化する場合、従来のIGPルーティングプロトコルまたは異なるサービスクラスに対して鈍感であるトラフィックエンジニアリング機構に排他的に依存することは十分でないかもしれません。代わりに、特に、サービスクラスごとに、制御およびマッピング機能をルーティング、トラフィック・エンジニアリングを実行することが望ましい場合があります。 MPLSとDiffservの両方をサポートするドメインにこれを達成する一つの方法は、クラスの特定のLSPを定義し、そのサービスクラスに対応する1つのまたは複数のLSPに各クラスからのトラフィックをマッピングすることです。与えられたサービスクラスに対応するLSPは、特定のポリシーに従って、ルーティング及びクラス依存的に回復/保護することができます。
Performing traffic engineering on a per class basis may require certain per-class parameters to be distributed. Note that it is common to have some classes share some aggregate constraint (e.g., maximum bandwidth requirement) without enforcing the constraint on each individual class. These classes then can be grouped into a class-type and per-class-type parameters can be distributed instead to improve scalability. It also allows better bandwidth sharing between classes in the same class-type. A class-type is a set of classes that satisfy the following two conditions:
クラスごとにトラフィック・エンジニアリングを実行すると、配信される特定のクラスごとのパラメータが必要な場合があります。いくつかのクラスは、個々のクラスに制約を強制することなく、いくつかの集計制約（例えば、最大帯域幅要件）を共有有することが一般的であることに留意されたいです。これらのクラスは、クラス型に分類することができ、クラス毎の型パラメータは、スケーラビリティを向上させる代わりに分散させることができます。また、同じクラス型で、クラス間のより良い帯域幅を共有することができます。クラス型は、次の2つの条件を満たすクラスのセットです。
1) Classes in the same class-type have common aggregate requirements to satisfy required performance levels.
1）同じクラスタイプのクラスは、必要な性能レベルを満たすために、共通の集計要求を有します。
2) There is no requirement to be enforced at the level of individual class in the class-type. Note that it is still possible, nevertheless, to implement some priority policies for classes in the same class-type to permit preferential access to the class-type bandwidth through the use of preemption priorities.
2）クラスタイプ内の個々のクラスのレベルで適用される必要はありません。それにもかかわらず、先取優先順位を使用して、クラス型の帯域幅への優先アクセスを可能にするために、同じクラス型のクラスのためのいくつかの優先順位ポリシーを実装するために、それはまだ可能であることに注意してください。
An example of the class-type can be a low-loss class-type that includes both AF1-based and AF2-based Ordering Aggregates. With such a class-type, one may implement some priority policy which assigns higher preemption priority to AF1-based traffic trunks over AF2-based ones, vice versa, or the same priority.
クラス型の例では、両方のAF1ベースとAF2ベース発注凝集体を含む低損失クラスタイプであってもよいです。そのようなクラス型と、一方がAF2ベースのもの、その逆、または同じ優先オーバーAF1ベースのトラフィックトランクに高い先取り優先順位を割り当てるいくつかの優先ポリシーを実施することができます。
See [DIFF-TE] for detailed requirements on Diffserv-aware traffic engineering.
Diffservの対応のトラフィックエンジニアリングに関する詳細な要件については、[DIFF-TE]を参照してください。
Off-line (and on-line) traffic engineering considerations would be of limited utility if the network could not be controlled effectively to implement the results of TE decisions and to achieve desired network performance objectives. Capacity augmentation is a coarse grained solution to traffic engineering issues. However, it is simple and may be advantageous if bandwidth is abundant and cheap or if the current or expected network workload demands it. However, bandwidth is not always abundant and cheap, and the workload may not always demand additional capacity. Adjustments of administrative weights and other parameters associated with routing protocols provide finer grained control, but is difficult to use and imprecise because of the routing interactions that occur across the network. In certain network contexts, more flexible, finer grained approaches which provide more precise control over the mapping of traffic to routes and over the selection and placement of routes may be appropriate and useful.
ネットワークはTEの決定の結果を実装し、目的のネットワーク性能目標を達成するために効果的に制御することができなかった場合はオフライン（及びオンライン）トラフィックエンジニアリングの考慮事項は、限られたユーティリティであろう。容量の増強は、トラフィックエンジニアリングの問題への粗粒度のソリューションです。しかし、それは簡単で、帯域幅が豊富で安価である場合、または現在または予想されるネットワークの負荷がそれを要求する場合が有利であり得ます。しかし、帯域幅は常に豊富で安価ではなく、ワークロードは、常に追加の容量を要求しないかもしれません。管理重みとルーティングプロトコルに関連する他のパラメータの調整は、より細かい粒度の制御を提供するが、なぜならネットワークを介して起こるルーティング相互作用の使用が困難で不正確です。特定のネットワークのコンテキストでは、ルートおよびルートの選択と配置上のトラフィックのマッピングをより正確な制御を提供する、より柔軟な、より細かい粒度のアプローチは、適切かつ有用であり得ます。
Control mechanisms can be manual (e.g., administrative configuration), partially-automated (e.g., scripts) or fully-automated (e.g., policy based management systems). Automated mechanisms are particularly required in large scale networks. Multi-vendor interoperability can be facilitated by developing and deploying standardized management systems (e.g., standard MIBs) and policies (PIBs) to support the control functions required to address traffic engineering objectives such as load distribution and protection/restoration.
制御機構は、完全に自動化された（例えば、管理構成）、部分的に自動化された（例えば、スクリプト）、または（例えば、ポリシーベースの管理システム）手動とすることができます。自動化メカニズムは、特に大規模ネットワークで必要とされます。マルチベンダーの相互運用性は、このような負荷分散と保護/復旧などのトラフィックエンジニアリングの目的に対処するために必要な制御機能をサポートするために、標準化された管理システム（例えば、標準MIB）とポリシー（PIBの）を開発し、展開することによって容易にすることができます。
Network control functions should be secure, reliable, and stable as these are often needed to operate correctly in times of network impairments (e.g., during network congestion or security attacks).
これらは多くの場合、（ネットワークの輻輳やセキュリティ攻撃の際に、例えば、）ネットワーク障害の時代に正しく動作するために必要とされるように、ネットワーク制御機能は、セキュアで信頼性が高く、安定していなければなりません。
Inter-domain traffic engineering is concerned with the performance optimization for traffic that originates in one administrative domain and terminates in a different one.
ドメイン間のトラフィックエンジニアリングは、1つの管理ドメインに由来し、別の1で終了するトラフィックのパフォーマンスの最適化に関するものです。
Traffic exchange between autonomous systems in the Internet occurs through exterior gateway protocols. Currently, BGP [BGP4] is the standard exterior gateway protocol for the Internet. BGP provides a number of attributes and capabilities (e.g., route filtering) that can be used for inter-domain traffic engineering. More specifically, BGP permits the control of routing information and traffic exchange between Autonomous Systems (AS's) in the Internet. BGP incorporates a sequential decision process which calculates the degree of preference for various routes to a given destination network. There are two fundamental aspects to inter-domain traffic engineering using BGP:
インターネットでの自律システム間のトラフィック交換は、外部ゲートウェイプロトコルを介して行われます。現在、BGP [BGP4]はインターネットのための標準的な外部ゲートウェイプロトコルです。 BGPは、インタードメイントラフィックエンジニアリングのために使用できる属性と機能の数（例えば、経路フィルタリング）を提供します。具体的には、BGPは、インターネットでの自律システム（ASさん）との間での情報とトラフィック交換をルーティングの制御を可能にします。 BGPは、所与の宛先ネットワークへの様々な経路の優先度を算出するシーケンシャル決定プロセスを組み込んでいます。 BGPを使用したドメイン間のトラフィックエンジニアリングには、2つの基本的な側面があります。
- Route Redistribution: controlling the import and export of routes between AS's, and controlling the redistribution of routes between BGP and other protocols within an AS.
- ルート再配布：ASの間のルートのインポートおよびエクスポートを制御し、BGPおよびAS内の他のプロトコル間でルートの再配布を制御します。
- Best path selection: selecting the best path when there are multiple candidate paths to a given destination network. Best path selection is performed by the BGP decision process based on a sequential procedure, taking a number of different considerations into account. Ultimately, best path selection under BGP boils down to selecting preferred exit points out of an AS towards specific destination networks. The BGP path selection process can be influenced by manipulating the attributes associated with the BGP decision process. These attributes include: NEXT-HOP, WEIGHT (Cisco proprietary which is also implemented by some other vendors), LOCAL-PREFERENCE, AS-PATH, ROUTE-ORIGIN, MULTI-EXIT-DESCRIMINATOR (MED), IGP METRIC, etc.
- ベストパス選択：指定された宛先ネットワークに複数の候補パスがある場合に最適なパスを選択します。ベストパス選択を考慮に異なる検討事項の数を取って、シーケンシャル手順に基づいてBGP決定プロセスによって行われます。最終的に、BGPの下で最良のパス選択はAS特定の宛先ネットワークに向けてのうち好ましい出口点を選択することに帰着します。 BGPパス選択プロセスは、BGP決定プロセスに関連付けられた属性を操作することによって、影響を受ける可能性があります。これらの属性が含まれます：NEXT-HOP、WEIGHT（また、いくつかの他のベンダーによって実装されるシスコ独自）、LOCAL-PREFERENCE、AS-PATH、ROUTE-ORIGIN、MULTI-EXIT-DESCRIMINATOR（MED）を、IGP METRICなど
Route-maps provide the flexibility to implement complex BGP policies based on pre-configured logical conditions. In particular, Route-maps can be used to control import and export policies for incoming and outgoing routes, control the redistribution of routes between BGP and other protocols, and influence the selection of best paths by manipulating the attributes associated with the BGP decision process. Very complex logical expressions that implement various types of policies can be implemented using a combination of Route-maps, BGP-attributes, Access-lists, and Community attributes.
ルートマップは、あらかじめ設定された論理条件に基づいて、複雑なBGPポリシーを実装するための柔軟性を提供します。具体的には、ルートマップは、着信および発信ルートのインポートおよびエクスポートポリシーを制御BGPと他のプロトコルとの間のルートの再配布を制御し、BGP決定プロセスに関連する属性を操作することで、最良のパスの選択に影響を与えるために使用することができます。政策の様々なタイプを実装する非常に複雑な論理式は、ルートマップ、BGP-属性、アクセス・リストの組み合わせを用いて実現することができる、とコミュニティ属性。
When looking at possible strategies for inter-domain TE with BGP, it must be noted that the outbound traffic exit point is controllable, whereas the interconnection point where inbound traffic is received from an EBGP peer typically is not, unless a special arrangement is made with the peer sending the traffic. Therefore, it is up to each individual network to implement sound TE strategies that deal with the efficient delivery of outbound traffic from one's customers to one's peering points. The vast majority of TE policy is based upon a "closest exit" strategy, which offloads interdomain traffic at the nearest outbound peer point towards the destination autonomous system. Most methods of manipulating the point at which inbound traffic enters a network from an EBGP peer (inconsistent route announcements between peering points, AS pre-pending, and sending MEDs) are either ineffective, or not accepted in the peering community.
BGPとドメイン間TEのための可能な戦略を見ると、一般的ではありませんインバウンドトラフィックは、EBGPピアから受信された相互接続点に対し、特別な取り決めをして作られていない限り、アウトバウンドトラフィックの出口点は、制御可能であることに留意しなければなりませんトラフィックを送信するピア。したがって、それは自分のピアリングポイントに1社の顧客からのアウトバウンドトラフィックの効率的な配信を扱う音TE戦略を実装するために、個々のネットワークに任されています。 TE政策の大半は、宛先自律システムへの最寄りのアウトバウンドピアポイントでドメイン間のトラフィックをオフロードし、「最も近いの出口」戦略、基づいています。インバウンドトラフィック（事前ペンディング、及び薬物の送信など、ピアリングポイント間の一貫性のない経路アナウンス）EBGPピアからネットワークに入る点を操作するほとんどの方法は効果がない、またはピアリングコミュニティに受け入れられていないのいずれかです。
Inter-domain TE with BGP is generally effective, but it is usually applied in a trial-and-error fashion. A systematic approach for inter-domain traffic engineering is yet to be devised.
BGPとドメイン間TEは、一般的に有効であるが、それは通常、試行錯誤の方式で適用されます。ドメイン間のトラフィックエンジニアリングのための体系的なアプローチは、まだ工夫があります。
Inter-domain TE is inherently more difficult than intra-domain TE under the current Internet architecture. The reasons for this are both technical and administrative. Technically, while topology and link state information are helpful for mapping traffic more effectively, BGP does not propagate such information across domain boundaries for stability and scalability reasons. Administratively, there are differences in operating costs and network capacities between domains. Generally, what may be considered a good solution in one domain may not necessarily be a good solution in another domain. Moreover, it would generally be considered inadvisable for one domain to permit another domain to influence the routing and management of traffic in its network.
ドメイン間TEは、現在のインターネットアーキテクチャの下で、本質的に、ドメイン内TEよりも困難です。この理由は、技術と管理の両方です。トポロジとリンク状態情報をより効果的にマッピングするトラフィックのために有用である一方で技術的には、BGPは、安定性と拡張性の理由から、ドメインの境界を越えて、このような情報を伝播しません。管理上、運用コストとドメイン間のネットワーク容量の違いがあります。一般的に、どのような1個のドメインで良い解決策は必ずしも別のドメインの良い解決策ではないかもしれないと考えることができます。 1つのドメインはそのネットワーク内のトラフィックのルーティングおよび管理に影響を与えるために別のドメインを許可するためにまた、それは一般的にお勧めできませんと考えられます。
MPLS TE-tunnels (explicit LSPs) can potentially add a degree of flexibility in the selection of exit points for inter-domain routing. The concept of relative and absolute metrics can be applied to this purpose. The idea is that if BGP attributes are defined such that the BGP decision process depends on IGP metrics to select exit points for inter-domain traffic, then some inter-domain traffic destined to a given peer network can be made to prefer a specific exit point by establishing a TE-tunnel between the router making the selection to the peering point via a TE-tunnel and assigning the TE-tunnel a metric which is smaller than the IGP cost to all other peering points. If a peer accepts and processes MEDs, then a similar MPLS TE-tunnel based scheme can be applied to cause certain entrance points to be preferred by setting MED to be an IGP cost, which has been modified by the tunnel metric.
MPLS TE-トンネル（明示的にLSPは）潜在ドメイン間ルーティングのための出口点の選択の自由度を追加することができます。相対と絶対のメトリックの概念は、この目的のために適用することができます。アイデアは、BGP属性は、BGP決定プロセスは、ドメイン間のトラフィックのための出口点を選択するために、IGPメトリックに依存するように定義されている場合、所与のピアネットワーク宛いくつかのドメイン間のトラフィックは、特定の出口点を優先させることができることですTEトンネルを介してピアリングポイントの選択を行うルータ間のTEトンネルを確立し、他のすべてのピアリングポイントにIGPコストよりも小さいメトリックTEトンネルを割り当てること。ピアが受け入れ、医療検査素子を処理した場合、同様のMPLS TEトンネルベースのスキームは、トンネルメトリックによって修飾されたIGPコストであるとMEDを設定することにより、好ましいことが特定の入口点を引き起こすために適用することができます。
Similar to intra-domain TE, inter-domain TE is best accomplished when a traffic matrix can be derived to depict the volume of traffic from one autonomous system to another.
イントラドメインTEと同様、トラフィック行列を別の自律システムからのトラフィックの量を示すように誘導することができる場合、ドメイン間TEが最もよく達成されます。
Generally, redistribution of inter-domain traffic requires coordination between peering partners. An export policy in one domain that results in load redistribution across peer points with another domain can significantly affect the local traffic matrix inside the domain of the peering partner. This, in turn, will affect the intra-domain TE due to changes in the spatial distribution of traffic. Therefore, it is mutually beneficial for peering partners to coordinate with each other before attempting any policy changes that may result in significant shifts in inter-domain traffic. In certain contexts, this coordination can be quite challenging due to technical and non- technical reasons.
一般的に、ドメイン間のトラフィックの再分配は、ピアリングパートナー間の調整が必要となります。別のドメインでのピア・ポイント間の負荷の再分配をもたらすもののドメインの輸出政策は大幅にピアリングパートナーのドメイン内のローカルトラフィック行列に影響を与えることができます。これは、順番に、トラフィックの空間分布の変化にドメイン内TEに影響します。従って、ドメイン間のトラフィックの大幅なシフトをもたらすことができる任意のポリシーの変更を試みる前に、互いに協調するパートナーをピアリングするための相互に有益です。特定のコンテキストでは、この調整は、技術的および非技術的な理由により、非常に困難な場合があります。
It is a matter of speculation as to whether MPLS, or similar technologies, can be extended to allow selection of constrained paths across domain boundaries.
これは、MPLS、または同様の技術は、ドメインの境界を越えて拘束されたパスの選択を可能にするように拡張することができるかどうかについての推測の問題です。
This section provides an overview of some contemporary traffic engineering practices in IP networks. The focus is primarily on the aspects that pertain to the control of the routing function in operational contexts. The intent here is to provide an overview of the commonly used practices. The discussion is not intended to be exhaustive.
このセクションでは、IPネットワークにおけるいくつかの現代的なトラフィックエンジニアリングの実践の概要を説明します。焦点は、主に運用コンテキストにおけるルーティング機能の制御に関連する側面にあります。ここでの意図は、一般的に使用されるプラクティスの概要を提供することです。議論は、網羅的であることを意図したものではありません。
Currently, service providers apply many of the traffic engineering mechanisms discussed in this document to optimize the performance of their IP networks. These techniques include capacity planning for long time scales, routing control using IGP metrics and MPLS for medium time scales, the overlay model also for medium time scales, and traffic management mechanisms for short time scale.
現在、サービスプロバイダーはIPネットワークのパフォーマンスを最適化するために、このドキュメントで説明トラフィックエンジニアリングのメカニズムの多くを適用します。これらの技術は、長い時間スケールのためのキャパシティプランニング、ルーティング制御媒体時間スケールのためのIGPメトリックとMPLSを使用して、メディア時間スケールにもオーバーレイ・モデル、および短い時間スケールのためのトラフィック管理メカニズムを含みます。
When a service provider plans to build an IP network, or expand the capacity of an existing network, effective capacity planning should be an important component of the process. Such plans may take the following aspects into account: location of new nodes if any, existing and predicted traffic patterns, costs, link capacity, topology, routing design, and survivability.
サービスプロバイダーはIPネットワークを構築したり、既存のネットワークの容量を拡張することを計画した場合、効果的なキャパシティプランニングは、プロセスの重要な要素でなければなりません。もしあれば、新しいノードの位置を既存のトラフィックパターン、コスト、リンク容量、トポロジー、ルーティング設計、および生存率の予測：そのような計画は、アカウントに次の側面がかかる場合があります。
Performance optimization of operational networks is usually an ongoing process in which traffic statistics, performance parameters, and fault indicators are continually collected from the network. This empirical data is then analyzed and used to trigger various traffic engineering mechanisms. Tools that perform what-if analysis can also be used to assist the TE process by allowing various scenarios to be reviewed before a new set of configurations are implemented in the operational network.
運用ネットワークのパフォーマンスの最適化は、通常、トラフィック統計、性能パラメータ、および障害インジケータが継続的にネットワークから収集される継続的なプロセスです。この経験的データは、分析し、さまざまなトラフィックエンジニアリングのメカニズムをトリガするために使用されます。コンフィギュレーションの新しいセットが運用ネットワークに実装される前に、さまざまなシナリオを検討することを可能にすることによってTEプロセスを支援するためにも使用することができるもの-if分析を行うツール。
Traditionally, intra-domain real-time TE with IGP is done by increasing the OSPF or IS-IS metric of a congested link until enough traffic has been diverted from that link. This approach has some limitations as discussed in Section 6.2. Recently, some new intra-domain TE approaches/tools have been proposed [RR94][FT00][FT01][WANG]. Such approaches/tools take traffic matrix, network topology, and network performance objective(s) as input, and produce some link metrics and possibly some unequal load-sharing ratios to be set at the head-end routers of some ECMPs as output. These new progresses open new possibility for intra-domain TE with IGP to be done in a more systematic way.
伝統的に、IGPとドメイン内のリアルタイムTEは、OSPFを増やすことによって行われたり、十分なトラフィックがそのリンクから流用されるまで混雑したリンクのメトリックです。 6.2節で述べたように、このアプローチは、いくつかの制限があります。最近、いくつかの新しいドメイン内TE手法/ツールが提案されている[RR94] [FT00] [FT01] [WANG]。このようなアプローチ/ツールは、入力として、トラフィック行列、ネットワークトポロジ、およびネットワークパフォーマンス目標（複数可）をとり、そしていくつかのリンク・メトリックおよびおそらく出力として一部ECMPsのヘッドエンドルータに設定するためにいくつかの不均等な負荷分散比率を生じます。これらの新しいは、IGPは、より体系的な方法で行うことにすると、ドメイン内TEのためのオープンの新しい可能性を進みます。
The overlay model (IP over ATM or IP over Frame relay) is another approach which is commonly used in practice [AWD2]. The IP over ATM technique is no longer viewed favorably due to recent advances in MPLS and router hardware technology.
（フレームリレー上ATM又はIPオーバーIP）オーバーレイ・モデルは、一般に[AWD2】実際に使用されている別のアプローチです。 ATM技術上のIPはもはやによるMPLSルータハードウェア技術の最近の進歩に好意的に閲覧されていません。
Deployment of MPLS for traffic engineering applications has commenced in some service provider networks. One operational scenario is to deploy MPLS in conjunction with an IGP (IS-IS-TE or OSPF-TE) that supports the traffic engineering extensions, in conjunction with constraint-based routing for explicit route computations, and a signaling protocol (e.g., RSVP-TE or CRLDP) for LSP instantiation.
トラフィックエンジニアリングアプリケーションのためのMPLSの導入は、いくつかのサービスプロバイダーのネットワークで開始されています。一つの動作シナリオは、明示的なルート計算に関する制約ベースのルーティングと連携して、トラフィックエンジニアリングの拡張をサポートしIGP（IS-IS-TEまたはOSPF-TE）と一緒にMPLSを展開することで、シグナリングプロトコル（例えば、RSVP LSPのインスタンス化のために-TEまたはCRLDP）。
In contemporary MPLS traffic engineering contexts, network administrators specify and configure link attributes and resource constraints such as maximum reservable bandwidth and resource class attributes for links (interfaces) within the MPLS domain. A link state protocol that supports TE extensions (IS-IS-TE or OSPF-TE) is used to propagate information about network topology and link attribute to all routers in the routing area. Network administrators also specify all the LSPs that are to originate each router. For each LSP, the network administrator specifies the destination node and the attributes of the LSP which indicate the requirements that to be satisfied during the path selection process. Each router then uses a local constraint-based routing process to compute explicit paths for all LSPs originating from it. Subsequently, a signaling protocol is used to instantiate the LSPs. By assigning proper bandwidth values to links and LSPs, congestion caused by uneven traffic distribution can generally be avoided or mitigated.
現代的なMPLSトラフィックエンジニアリングのコンテキストでは、ネットワーク管理者は、このようなクラスは、MPLSドメイン内のリンク（インタフェース）の属性の最大予約可能帯域幅およびリソースとしてリンク属性とリソースの制約を指定して設定します。 TE拡張（IS-IS-TEまたはOSPF-TE）をサポートするリンク状態プロトコルは、ルーティング領域内のすべてのルータにネットワークトポロジとリンク属性に関する情報を伝播するために使用されます。ネットワーク管理者は、各ルータを発信しているすべてのLSPを指定します。各LSPのために、ネットワーク管理者は、宛先ノードと経路選択プロセス中に満たすべき要件を示すLSPの属性を指定します。各ルータは、それに由来する全てのLSPの明示的なパスを計算するためにローカル制約ベースのルーティング処理を使用します。その後、シグナリングプロトコルはLSPをインスタンス化するために使用されます。リンクとのLSPに適切な帯域幅の値を割り当てることで、不均一なトラフィック分散に起因する輻輳は、一般的に回避または軽減することができます。
The bandwidth attributes of LSPs used for traffic engineering can be updated periodically. The basic concept is that the bandwidth assigned to an LSP should relate in some manner to the bandwidth requirements of traffic that actually flows through the LSP. The traffic attribute of an LSP can be modified to accommodate traffic growth and persistent traffic shifts. If network congestion occurs due to some unexpected events, existing LSPs can be rerouted to alleviate the situation or network administrator can configure new LSPs to divert some traffic to alternative paths. The reservable bandwidth of the congested links can also be reduced to force some LSPs to be rerouted to other paths.
トラフィックエンジニアリングのために使用されたLSPの帯域幅の属性は定期的に更新することができます。基本的なコンセプトは、LSPに割り当てられた帯域幅は、実際にLSPを流れるトラフィックの帯域幅要件に何らかの形で関係するべきであるということです。 LSPのトラフィック属性は、トラフィックの成長と持続的なトラフィックシフトに対応するために変更することができます。ネットワークの輻輳が何らかの予期しないイベントに発生した場合、既存のLSPは、代替パスにいくつかのトラフィックをそらすために新しいLSPを設定することができ、状況やネットワーク管理者を軽減するために再ルーティングすることができます。輻輳したリンクの予約可能帯域幅は、他の経路に再ルーティングするためにいくつかのLSPを強制的に減少させることができます。
In an MPLS domain, a traffic matrix can also be estimated by monitoring the traffic on LSPs. Such traffic statistics can be used for a variety of purposes including network planning and network optimization. Current practice suggests that deploying an MPLS network consisting of hundreds of routers and thousands of LSPs is feasible. In summary, recent deployment experience suggests that MPLS approach is very effective for traffic engineering in IP networks [XIAO].
MPLSドメインでは、トラフィック行列ものLSP上のトラフィックを監視することによって推定することができます。このようなトラフィック統計は、ネットワークプランニングおよびネットワークの最適化など、様々な目的のために使用することができます。現在の練習は、LSPのルーターと数十万人からなるMPLSネットワークを展開することは可能であることを示唆しています。要約すると、最近の展開の経験は、MPLSのアプローチは、IPネットワーク[XIAO]におけるトラフィックエンジニアリングのために非常に有効であることを示唆しています。
As mentioned previously in Section 7.0, one usually has no direct control over the distribution of inbound traffic. Therefore, the main goal of contemporary inter-domain TE is to optimize the distribution of outbound traffic between multiple inter-domain links. When operating a global network, maintaining the ability to operate the network in a regional fashion where desired, while continuing to take advantage of the benefits of a global network, also becomes an important objective.
セクション7.0で前述したように、一つは通常、着信トラフィックの分布の直接制御を持っていません。したがって、現代のドメイン間TEの主な目的は、複数のドメイン間リンク間のアウトバウンドトラフィックの分布を最適化することです。グローバルネットワークの利点を活用するために継続しながら、希望の地域の方式でネットワークを動作する能力を維持し、グローバルネットワークを動作させる場合、また、重要な目的となります。
Inter-domain TE with BGP usually begins with the placement of multiple peering interconnection points in locations that have high peer density, are in close proximity to originating/terminating traffic locations on one's own network, and are lowest in cost. There are generally several locations in each region of the world where the vast majority of major networks congregate and interconnect. Some location-decision problems that arise in association with inter-domain routing are discussed in [AWD5].
BGPとドメイン間TEは通常、高いピア密度を持って、自分のネットワーク上のトラフィックの場所を終端/発信元に近接しており、コストが最低のある場所で複数のピアリングの相互接続点の配置から始まります。主要なネットワークの大多数が集まる世界との相互接続の各領域におけるいくつかの場所は、一般的にあります。ドメイン間ルーティングに関連して生じるいくつかの位置決定の問題は[AWD5]に記載されています。
Once the locations of the interconnects are determined, and circuits are implemented, one decides how best to handle the routes heard from the peer, as well as how to propagate the peers' routes within one's own network. One way to engineer outbound traffic flows on a network with many EBGP peers is to create a hierarchy of peers. Generally, the Local Preferences of all peers are set to the same value so that the shortest AS paths will be chosen to forward traffic. Then, by over-writing the inbound MED metric (Multi-exit-discriminator metric, also referred to as "BGP metric". Both terms are used interchangeably in this document) with BGP metrics to routes received at different peers, the hierarchy can be formed. For example, all Local Preferences can be set to 200, preferred private peers can be assigned a BGP metric of 50, the rest of the private peers can be assigned a BGP metric of 100, and public peers can be assigned a BGP metric of 600. "Preferred" peers might be defined as those peers with whom the most available capacity exists, whose customer base is larger in comparison to other peers, whose interconnection costs are the lowest, and with whom upgrading existing capacity is the easiest. In a network with low utilization at the edge, this works well. The same concept could be applied to a network with higher edge utilization by creating more levels of BGP metrics between peers, allowing for more granularity in selecting the exit points for traffic bound for a dual homed customer on a peer's network.
相互接続の位置が決定され、回路が実装されると、1は最高の自分のネットワーク内のピアのルートを伝播する方法だけでなく、仲間から聞いたルートをどのように処理するかを決定します。アウトバウンドトラフィックを設計するための一つの方法は、多くのEBGPピアとネットワーク上を流れるピアの階層を作成することです。パスAS最短でトラフィックを転送するために選択されるように、一般的に、すべてのピアのローカルプリファレンスは、同じ値に設定されています。次いで、過書き込みインバウンドMEDメトリックによって（また、「メトリックBGP」と呼ばれるマルチ出口弁別器メトリックを、両方の用語は本書では互換的に使用される）BGPメトリックを有するルートに異なるピアで受信され、階層構造とすることができます形成。たとえば、すべてのローカルプリファレンスを200に設定することができ、好適なプライベートピアは50のBGPメトリックを割り当てることができ、プライベートピアの残りの部分は100のBGPメトリックを割り当てることができ、および公共ピアは600のBGPメトリックを割り当てることができます。「優先」ピアは、これらのピアのように定義されるかもしれない、その顧客基盤の相互接続コスト最低、およびアップグレードと既存の容量が最も簡単ですしている他のピア、と比較して大きくなっている人ほとんど空き容量が存在している、と。エッジでの使用率が低いとのネットワークでは、これはうまく動作します。同じ概念は、ピアのネットワーク上のデュアルホームの顧客のためにバインドされたトラフィックのための出口点を選択する上で、より粒度を考慮して、ピア間のBGPメトリックのより多くのレベルを作成することによって、高いエッジ利用してネットワークにも適用することができます。
By only replacing inbound MED metrics with BGP metrics, only equal AS-Path length routes' exit points are being changed. (The BGP decision considers Local Preference first, then AS-Path length, and then BGP metric). For example, assume a network has two possible egress points, peer A and peer B. Each peer has 40% of the Internet's routes exclusively on its network, while the remaining 20% of the Internet's routes are from customers who dual home between A and B. Assume that both peers have a Local Preference of 200 and a BGP metric of 100. If the link to peer A is congested, increasing its BGP metric while leaving the Local Preference at 200 will ensure that the 20% of total routes belonging to dual homed customers will prefer peer B as the exit point. The previous example would be used in a situation where all exit points to a given peer were close to congestion levels, and traffic needed to be shifted away from that peer entirely.
のみBGPメトリックとインバウンドMEDメトリックを置き換えることによって、唯一同じASパス長ルート出口点が変更されています。 （BGP決定ローカル最初嗜好、ASパス長さ、及びその後BGPメトリックを考慮する）。例えば、インターネットのルートの残りの20％はAとの間に二重の家顧客からのものながら、各ピアは、そのネットワーク上で独占的にインターネットのルートの40％を持っているネットワークは、2つの可能出口ポイント、ピアAとピアBを持っていると仮定し、 B.総経路の20％がに属していることを保証します200にローカルプリファレンスを残しながらそのBGPメトリックを増加させる、両方のピア200のローカルプリファレンス及びAピアへのリンクが混雑している場合は100のBGPメトリックを持っていると仮定しますデュアルホームのお客様には、出口点として、ピアBを好むでしょう。前の例では、所与のピアへのすべての出口点は、輻輳レベルに近かった、トラフィックは完全にそのピアから離れるようにシフトされる必要な状況で使用されるであろう。
When there are multiple exit points to a given peer, and only one of them is congested, it is not necessary to shift traffic away from the peer entirely, but only from the one congested circuit. This can be achieved by using passive IGP-metrics, AS-path filtering, or prefix filtering.
そこに複数の出口ポイントが与えられたピアにあり、それらの一方のみが輻輳している場合、完全に離れて、ピアからのトラフィックをシフトする必要はないが、一つだけ輻輳回路から。これは、ASパスフィルタリング、またはプレフィックスフィルタリングを受動IGPメトリックを使用することによって達成することができます。
Occasionally, more drastic changes are needed, for example, in dealing with a "problem peer" who is difficult to work with on upgrades or is charging high prices for connectivity to their network. In that case, the Local Preference to that peer can be reduced below the level of other peers. This effectively reduces the amount of traffic sent to that peer to only originating traffic (assuming no transit providers are involved). This type of change can affect a large amount of traffic, and is only used after other methods have failed to provide the desired results.
時折、より大幅な変更は、アップグレードにして作業することは困難であるか、そのネットワークへの接続に高い価格を充電している「問題ピア」に対処するには、例えば、必要とされています。その場合には、そのピアのローカルプリファレンスは、他のピアのレベル以下に低減することができます。これは、効果的にトラフィックのみを発信する（プロバイダが関与している何の輸送を想定していない）にそのピアに送信されたトラフィックの量を減らすことができます。変更のこのタイプは、大量のトラフィックに影響を与えることができ、そして他の方法は、望ましい結果を提供することができなかった後にのみ使用されます。
Although it is not much of an issue in regional networks, the propagation of a peer's routes back through the network must be considered when a network is peering on a global scale. Sometimes, business considerations can influence the choice of BGP policies in a given context. For example, it may be imprudent, from a business perspective, to operate a global network and provide full access to the global customer base to a small network in a particular country. However, for the purpose of providing one's own customers with quality service in a particular region, good connectivity to that in-country network may still be necessary. This can be achieved by assigning a set of communities at the edge of the network, which have a known behavior when routes tagged with those communities are propagating back through the core. Routes heard from local peers will be prevented from propagating back to the global network, whereas routes learned from larger peers may be allowed to propagate freely throughout the entire global network. By implementing a flexible community strategy, the benefits of using a single global AS Number (ASN) can be realized, while the benefits of operating regional networks can also be taken advantage of. An alternative to doing this is to use different ASNs in different regions, with the consequence that the AS path length for routes announced by that service provider will increase.
それは地域ネットワークにおける問題の多くはありませんが、ネットワークが世界的規模でピアリングされたときに、バックネットワークを介してピアのルートの伝播が考慮されなければなりません。時には、ビジネス上の考慮事項は、指定されたコンテキストでBGPポリシーの選択に影響を与えることができます。例えば、それは、グローバルネットワークを運営し、特定の国で小規模ネットワークへのグローバルな顧客基盤への完全なアクセスを提供するために、ビジネスの観点から、軽率かもしれません。しかし、特定の地域における質の高いサービスを自分の顧客に提供することを目的として、その中に国内ネットワークへの良好な接続がまだ必要な場合があります。これは、これらのコミュニティでタグ付けされたルートがバックコアを通って伝播される既知の挙動を有するネットワークのエッジでコミュニティのセットを割り当てることによって達成することができます。大きいピアから学習した経路全体グローバルネットワークを通じて自由に伝播させることができる一方、ローカルピアから聞いたルートは、グローバルネットワークに戻って伝播することを防止します。オペレーティング地域ネットワークのメリットもの利点を撮影することができますしながら、柔軟なコミュニティ戦略を実装することで、単一のグローバルAS番号（ASN）を使用する利点は、実現することができます。これを実行する代わりに、そのサービスプロバイダによって発表されたルートのASパス長が増加する結果と、異なる領域に異なるのASNを使用することです。
This document described principles for traffic engineering in the Internet. It presented an overview of some of the basic issues surrounding traffic engineering in IP networks. The context of TE was described, a TE process models and a taxonomy of TE styles were presented. A brief historical review of pertinent developments related to traffic engineering was provided. A survey of contemporary TE techniques in operational networks was presented. Additionally, the document specified a set of generic requirements, recommendations, and options for Internet traffic engineering.
この文書は、インターネットのトラフィックエンジニアリングのための原則を説明しました。これは、IPネットワーク内のトラフィックエンジニアリングを取り巻く基本的な問題のいくつかの概要を発表しました。 TEのコンテキストは、TEプロセスモデルを説明し、TEスタイルの分類を提示しました。トラフィックエンジニアリングに関連する適切な発展の簡単な歴史的な検討が提供されていました。運用ネットワークで現代的なTE技術の調査が発表されました。また、ドキュメントはインターネットトラフィックエンジニアリングのための一般的な要件、推奨事項、およびオプションのセットを指定しました。
This document does not introduce new security issues.
この文書は、新しいセキュリティ問題を紹介しません。
The authors would like to thank Jim Boyle for inputs on the recommendations section, Francois Le Faucheur for inputs on Diffserv aspects, Blaine Christian for inputs on measurement, Gerald Ash for inputs on routing in telephone networks and for text on event-dependent TE methods, Steven Wright for inputs on network controllability, and Jonathan Aufderheide for inputs on inter-domain TE with BGP. Special thanks to Randy Bush for proposing the TE taxonomy based on "tactical vs strategic" methods. The subsection describing an "Overview of ITU Activities Related to Traffic Engineering" was adapted from a contribution by Waisum Lai. Useful feedback and pointers to relevant materials were provided by J. Noel Chiappa. Additional comments were provided by Glenn Grotefeld during the working last call process. Finally, the authors would like to thank Ed Kern, the TEWG co-chair, for his comments and support.
著者は、電話網におけるルーティング上およびイベント依存TE法上のテキストの入力のためにジェラルド・アッシュ、測定上の入力用のDiffservの側面に入力するための推奨事項のセクション、フランソワ・ルFaucheur上の入力についてジム・ボイル、ブレインクリスチャンに感謝したいと思い、 BGPとドメイン間TE上の入力のためのネットワーク制御上の入力のスティーヴン・ライト、およびジョナサンAufderheide。メソッド「戦略的な対戦術的」に基づいて、TEの分類法を提案するためのランディブッシュに感謝します。 「トラフィックエンジニアリングに関連するITU活動の概要」を記述したサブセクションはWaisumライによる寄与から適応されました。有用なフィードバックと関連資料へのポインタは、J。クリスマスChiappaによって提供されました。追加のコメントは作業の最後の呼び出し処理中にグレンGrotefeldによって提供されました。最後に、著者は彼のコメントやサポートのために、エド・カーン、TEWGの共同議長に感謝したいと思います。
[ASH2] J. Ash, Dynamic Routing in Telecommunications Networks, McGraw Hill, 1998.
[ASH2] J.アッシュ、通信ネットワークにおける動的ルーティング、マグロウヒル、1998。
[ASH3] Ash, J., "TE & QoS Methods for IP-, ATM-, & TDM-Based Networks", Work in Progress, March 2001.
[AsH 3]アッシュ、J.、 "IP-、ATM-のためのTE＆QoSの方法、およびTDMベースのネットワーク"、進歩、2001年3月に作業。
[AWD1] D. Awduche and Y. Rekhter, "Multiprocotol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects", IEEE Communications Magazine, March 2001.
[AWD1] D. AwducheとY. Rekhter、 "Multiprocotolラムダスイッチング：光クロスコネクトとMPLSトラフィックエンジニアリングコントロールを組み合わせる"、IEEEコミュニケーションズ・マガジン、2001年3月。
[AWD2] D. Awduche, "MPLS and Traffic Engineering in IP Networks", IEEE Communications Magazine, Dec. 1999.
[AWD2] D. Awduche、 "MPLSおよびIPネットワークにおけるトラフィックエンジニアリング"、IEEE通信誌、1999年12月。
[AWD5] D. Awduche et al, "An Approach to Optimal Peering Between Autonomous Systems in the Internet", International Conference on Computer Communications and Networks (ICCCN'98), Oct. 1998.
[AWD5] D. Awducheら、「インターネットにおける自律システム間の最適なピアリングへのアプローチ」、コンピュータ通信とネットワークに関する国際会議（ICCCN'98）、1998年10月。
[CRUZ] R. L. Cruz, "A Calculus for Network Delay, Part II: Network Analysis", IEEE Transactions on Information Theory, vol. 37, pp. 132-141, 1991.
[CRUZ] R. L.クルス、 "ネットワーク遅延、パートIIのための微積分：ネットワーク分析"、情報理論、巻上のIEEEトランザクション。 37頁132から141、1991。
[DIFF-TE] Le Faucheur, F., Nadeau, T., Tatham, M., Telkamp, T., Cooper, D., Boyle, J., Lai, W., Fang, L., Ash, J., Hicks, P., Chui, A., Townsend, W. and D. Skalecki, "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering", Work in Progress, May 2001.
[DIFF-TE]ルFaucheur、F.、ナドー、T.、タサム、M.、Telkamp、T.、クーパー、D.、ボイル、J.、ライ、W.、牙、L.、灰、J. 、ヒックス、P.、チュイ、A.、タウンゼント、W.およびD. Skalecki、 "差分-Servのを意識したMPLSトラフィックエンジニアリングをサポートするための要件"、進歩、2001年5月での作業。
[ELW95] A. Elwalid, D. Mitra and R.H. Wentworth, "A New Approach for Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic in an ATM Node", IEEE IEEE Journal on Selected Areas in Communications, 13:6, pp. 1115-1127, Aug. 1995.
通信における選択された領域に[ELW95] A. Elwalid、D.ミトラ及びRHウェントワース、「異機種、ATMノードで規定されたトラフィックに割り当てバッファおよび帯域幅のための新しいアプローチ」、IEEE IEEEジャーナル、13：6、頁1115年。 -1127、1995年8月。
[FGLR] A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J. Rexford, "NetScope: Traffic Engineering for IP Networks", IEEE Network Magazine, 2000.
[FGLR] A.フェルドマン、A.グリーンバーグ、C.ルンド、N. Reingold、およびJ. Rexfordの、 "NetScope：IPネットワークのトラフィックエンジニアリング"、IEEEネットワークマガジン、2000。
[FLJA93] S. Floyd and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, Vol. 1 Nov. 4., p. 387-413, Aug. 1993.
「輻輳回避のためのランダム早期検出ゲートウェイ」[FLJA93] S.フロイドとV.ヤコブソン、ネットワーキング、巻上のIEEE / ACM取引。 11月1日4、P。 387から413まで、1993年8月。
[FLOY94] S. Floyd, "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24, No. 5, p. 10-23, Oct. 1994.
[FLOY94] S.フロイド、 "TCPおよび明示的輻輳通知"、ACMコンピュータコミュニケーションレビュー、V. 24、第5号、P。 10-23、1994年10月。
[FT00] B. Fortz and M. Thorup, "Internet Traffic Engineering by Optimizing OSPF Weights", IEEE INFOCOM 2000, Mar. 2000.
[FT00] B. FortzとM. Thorup、 "OSPFの重みを最適化することにより、インターネットトラフィックエンジニアリング"、IEEE INFOCOM 2000、2000年3月。
[FT01] B. Fortz and M. Thorup, "Optimizing OSPF/IS-IS Weights in a Changing World", www.research.att.com/~mthorup/PAPERS/papers.html.
[FT01] B. Fortz及びM. Thorup、www.research.att.com/~mthorup/PAPERS/papers.html "OSPFの最適化/変更世界における重み-IS"。
[HUSS87] B.R. Hurley, C.J.R. Seidl and W.F. Sewel, "A Survey of Dynamic Routing Methods for Circuit-Switched Traffic", IEEE Communication Magazine, Sep. 1987.
【HUSS87] B.R.ハーレー、C.J.R. SeidlとW.F. Sewel、「回線交換トラフィックのための動的ルーティング方法の調査」、IEEE通信誌、1987年9月。
[ITU-E600] ITU-T Recommendation E.600, "Terms and Definitions of Traffic Engineering", Mar. 1993.
[ITU-E600] ITU-T勧告E.600、 "本規約およびトラフィックエンジニアリングの定義"、1993年3月。
[ITU-E701] ITU-T Recommendation E.701, "Reference Connections for Traffic Engineering", Oct. 1993.
[ITU-E701] ITU-T勧告E.701、 "トラフィックエンジニアリングのためのリファレンス・コネクション"、1993年10月。
[ITU-E801] ITU-T Recommendation E.801, "Framework for Service Quality Agreement", Oct. 1996.
[ITU-E801] ITU-T勧告E.801、1996年10月 "サービス品質契約のための枠組み"。
[JAM] Jamoussi, B., Editior, Andersson, L., Collon, R. and R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[JAM] Jamoussi、B.、人気アニメ、アンダーソン、L.、Collonの、R.とR. Dantu、 "LDPを使用して制約ベースのLSPセットアップ"、RFC 3212、2002年1月。
[KATZ] Katz, D., Yeung, D. and K. Kompella, "Traffic Engineering Extensions to OSPF", Work in Progress, February 2001.
[KATZ]カッツ、D.、ヨン、D.及びK. Kompella、 "OSPFへのトラフィックエンジニアリングの拡張"、進歩、2001年2月に作業。
[LNO96] T. Lakshman, A. Neidhardt, and T. Ott, "The Drop from Front Strategy in TCP over ATM and its Interworking with other Control Features", Proc. INFOCOM'96, p. 1242-1250, 1996.
[LNO96] T.ラクシュマン、A.ナイトハルト、およびT.オット、「ATM上のTCPでのフロント戦略からのドロップや他の制御機能とのインターワーキング」、PROC。 INFOCOM'96、P。 1242-1250、1996。
[MA] Q. Ma, "Quality of Service Routing in Integrated Services Networks", PhD Dissertation, CMU-CS-98-138, CMU, 1998.
[MA] Q.馬、博士の学位論文、CMU-CS-98から138、CMU、1998年 "サービス統合型ネットワークにおけるサービスルーティングの品質"。
[MATE] A. Elwalid, C. Jin, S. Low, and I. Widjaja, "MATE: MPLS Adaptive Traffic Engineering", Proc. INFOCOM'01, Apr. 2001.
[MATE] A. Elwalid、C.ジン、S.低、及びI. Widjaja、 "MATE：MPLS適応トラフィックエンジニアリング"、PROC。 INFOCOM'01、2001年4月。
[MCQ80] J.M. McQuillan, I. Richer, and E.C. Rosen, "The New Routing Algorithm for the ARPANET", IEEE. Trans. on Communications, vol. 28, no. 5, pp. 711-719, May 1980.
[MCQ80] I.リシェJ.M. McQuillan氏の説明によると、E。C.ローゼン、 "ARPANETのための新しいルーティングアルゴリズム"、IEEE。トランス。コミュニケーション上の、巻。 28、ありません。 5頁711から719まで、1980年5月。
[MR99] D. Mitra and K.G. Ramakrishnan, "A Case Study of Multiservice, Multipriority Traffic Engineering Design for Data Networks", Proc. Globecom'99, Dec 1999.
[MR99] D.ミトラとK.G.ラマクリシュナン、「マルチサービスのケーススタディ、データネットワークのためのMultipriorityトラフィックエンジニアリングデザイン」、PROC。 Globecom'99、1999年12月。
[RFC-1458] Braudes, R. and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
[RFC-1458] Braudes、R.およびS. Zabele、 "マルチキャストプロトコルのための要件"、RFC 1458、1993年5月。
[RFC-1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC-1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC-1812] Baker, F., "Requirements for IP Version 4 Routers", STD 4, RFC 1812, June 1995.
[RFC-1812]ベイカー、F.、STD 4、RFC 1812 "IPバージョン4つのルータのための要件"、1995年6月。
[RFC-1992] Castineyra, I., Chiappa, N. and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC-1992] Castineyra、I.、Chiappa、N.およびM. Steenstrup、 "ニムロッドルーティングアーキテクチャ"、RFC 1992、1996年8月。
[RFC-1997] Chandra, R., Traina, P. and T. Li, "BGP Community Attributes", RFC 1997, August 1996.
[RFC-1997]チャンドラ、R.、Trainaの、P.およびT.李、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
[RFC-1998] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996.
[RFC-1998]チェン、E.とT.ベイツ、 "マルチホームルーティングでのBGPコミュニティ属性の応用"、RFC 1998、1996年8月。
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC-2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC-2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC-2211] Wroclawski、RFC 2211 J.、 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[RFC-2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC-2212] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC-2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC-2215] Shenker、S.とJ. Wroclawski、 "統合サービスネットワーク要素のための一般的な特性化パラメータ"、RFC 2215、1997年9月。
[RFC-2216] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.
[RFC-2216] Shenker、S.およびJ. Wroclawski、 "ネットワーク要素サービス仕様テンプレート"、RFC 2216、1997年9月。
[RFC-2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, July 1997.
[RFC-2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1997年7月。
[RFC-2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC-2330]パクソン、V.、Almes、G.、Mahdavi、J.とM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[RFC-2386] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
[RFC-2386]クローリー、E.、Nairさん、R.、Rajagopalan、B.及びH. Sandick、 "インターネットにおけるQoSベースのルーティングの枠組み"、RFC 2386、1998年8月。
[RFC-2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC-2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[RFC-2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC-2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC-2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC-2597] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC-2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[RFC-2678] Mahdavi、J.およびV.パクソン、 "接続を測定するためのIPPMメトリック"、RFC 2678、1999年9月。
[RFC-2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC-2679] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMための一方向遅延メトリック"、RFC 2679、1999年9月。
[RFC-2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC-2680] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMための一方向パケット損失メトリック"、RFC 2680、1999年9月。
[RFC-2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[RFC-2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、 "MPLSのトラフィックエンジニアリングのための要件"、RFC 2702、1999年9月。
[RFC-2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RFC-2722]ブラウンリー、N.、ミルズ、C.およびG.ルース、 "トラフィックフロー測定：アーキテクチャ"、RFC 2722、1999年10月。
[RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC-2753] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[RFC-2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2000.
[RFC-2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2000年4月。
[RFC-2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC-2998] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.及びE. Felstaine、 "Diffservのネットワーク経由の統合サービス操作のための枠組み"、RFC 2998、2000年11月。
[RFC-3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC-3031]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC-3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC-3086]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
[RFC-3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC-3124]バラクリシュナン、H.とS. Seshan、 "輻輳管理"、RFC 3124、2001年6月。
[RFC-3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC-3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、 2001年12月。
[RFC-3210] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001.
[RFC-3210] Awduche、D.、阪南、A.及びX.シャオ、 "LSP-トンネルのためのRSVPの拡張のための適用性に関する声明"、RFC 3210、2001年12月。
[RFC-3213] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G. Wright, "Applicability Statement for CR-LDP", RFC 3213, January 2002.
[RFC-3213]アッシュ、J.、Girish、M.、グレー、E.、Jamoussi、B.及びG.ライト、 "CR-LDPのための適用性に関する声明"、RFC 3213、2002年1月。
[RFC-3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaahanen, P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, April 2002.
[RFC-3270]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaahanen、P.、クリシュナン、R.、シュヴァル、P.及びJ. Heinanen、「マルチプロトコルラベル差別化サービスの（MPLS）サポート」、RFC 3270、2002年4月を切り替えます。
[RR94] M.A. Rodrigues and K.G. Ramakrishnan, "Optimal Routing in Shortest Path Networks", ITS'94, Rio de Janeiro, Brazil.
【RR94] M.A.ロドリゲスとK.G.ラマクリシュナン、「最適最短パスネットワークにおけるルーティング」、ITS'94、リオ・デ・ジャネイロ、ブラジル。
[SHAR] Sharma, V., Crane, B., Owens, K., Huang, C., Hellstrand, F., Weil, J., Anderson, L., Jamoussi, B., Cain, B., Civanlar, S. and A. Chui, "Framework for MPLS Based Recovery", Work in Progress.
[SHAR]シャルマ、V.、クレーン、B.、オーウェンズ、K.、黄、C.、Hellstrand、F.、ワイル、J.、アンダーソン、L.、Jamoussi、B.、カイン、B.、Civanlar、 S.とA.チュイ、「MPLSベースの回復のための枠組み」が進行中で働いています。
[SLDC98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury, "Design Considerations for Supporting TCP with Per-flow Queueing", Proc. INFOCOM'98, p. 299-306, 1998.
[SLDC98] B.スーター、T.ラクシュマン、D. Stiliadis、およびA.チョードリー、PROC "フローごとのキューイングとTCPをサポートするための設計上の考慮事項"。 INFOCOM'98、P。 299-306、1998。
[SMIT] Smit, H. and T. Li, "IS-IS extensions for Traffic Engineering", Work in Progress.
[SMIT]スミット、H.、およびT.李は、進行中で働いて "トラフィックエンジニアリング用の拡張機能-IS"。
[WANG] Y. Wang, Z. Wang, L. Zhang, "Internet traffic engineering without full mesh overlaying", Proceedings of INFOCOM'2001, April 2001.
[WANG] Y.ワング、Z.王、L.チャン、 "フルメッシュオーバーレイなしのインターネットトラフィックエンジニアリング"、INFOCOM'2001の議事録、2001年4月。
[XIAO] X. Xiao, A. Hannan, B. Bailey, L. Ni, "Traffic Engineering with MPLS in the Internet", IEEE Network magazine, Mar. 2000.
[XIAO] X.シャオ、A.阪南、B.ベイリー、L.ニッケル、 "インターネットにおけるMPLSとトラフィックエンジニアリング"、IEEEネットワーク誌、2000年3月。
[YARE95] C. Yang and A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks", IEEE Network Magazine, p. 34-45, 1995.
[YARE95] C.ヤンとA.レディ、「パケット交換網における輻輳制御アルゴリズムのための分類学」、IEEEネットワークマガジン、P。 34-45、1995。
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
ダニエルO. Awduche Movazネットワーク7926ジョーンズ支店ドライブ、スイート615マクリーン、VA 22102
Phone: 703-298-5291 EMail: awduche@movaz.com
電話：703-298-5291 Eメール：awduche@movaz.com
Angela Chiu Celion Networks 1 Sheila Dr., Suite 2 Tinton Falls, NJ 07724
アンジェラ・チウCelionネットワーク1シーラ博士は、スイート2ティントンフォールズ、NJ 07724
Phone: 732-747-9987 EMail: angela.chiu@celion.com
電話：732-747-9987 Eメール：angela.chiu@celion.com
Anwar Elwalid Lucent Technologies Murray Hill, NJ 07974
アンワルワリード1世は、マレー・テクノロジーズトリック、ン07 974だった場合
Phone: 908 582-7589 EMail: anwar@lucent.com
電話番号：908 582-7589 Eメール：anwar@lucent.com
Indra Widjaja Bell Labs, Lucent Technologies 600 Mountain Avenue Murray Hill, NJ 07974
インドラWidjajaベル研究所、ルーセント・テクノロジーズ600マウンテンアベニューマレー・ヒル、NJ 07974
Phone: 908 582-0435 EMail: iwidjaja@research.bell-labs.com
電話番号：908 582-0435 Eメール：iwidjaja@research.bell-labs.com
XiPeng Xiao Redback Networks 300 Holger Way San Jose, CA 95134
XiPengシャオレッドバック・ネットワーク300ホルガー・ウェイサンノゼ、CA 95134
Phone: 408-750-5217 EMail: xipeng@redback.com
電話：408-750-5217 Eメール：xipeng@redback.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。