[要約] RFC 3272は、インターネットトラフィックエンジニアリングの概要と原則について説明しています。このRFCの目的は、インターネットのトラフィック制御と最適化のための基本的な理解を提供することです。
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.
Copyright（c）The Internet Society（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.
インターネットトラフィックエンジニアリングは、エンドツーエンドで適用される場合に最も効果的ですが、このドキュメントドキュメントの最初の焦点はドメイン内トラフィックエンジニアリング（つまり、特定の自律システム内のトラフィックエンジニアリング）です。ただし、インターネットトラフィックの優勢はドメイン間（ある自律システムに由来し、別のシステムで終了する）になる傾向があるため、このドキュメントは、ドメイン間トラフィックエンジニアリングに関する側面の概要を提供します。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
ソースノードから宛先ノードに情報を転送するために、インターネットが存在します。したがって、インターネットで実行される最も重要な機能の1つは、イングレスノードからノードへの出力へのトラフィックのルーティングです。したがって、インターネットトラフィックエンジニアリングによって実行される最も特徴的な機能の1つは、最も効果的な方法でネットワークを通過するためのルーティング関数の制御と最適化です。
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.
交通工学の最適化の側面は、容量管理と交通管理を通じて達成できます。このドキュメントで使用されているように、容量管理には容量計画、ルーティング制御、およびリソース管理が含まれます。特に関心のあるネットワークリソースには、リンク帯域幅、バッファスペース、計算リソースが含まれます。同様に、このドキュメントで使用されているように、トラフィック管理には、（1）トラフィックコンディショニング、キュー管理、スケジューリング、（2）ネットワークを通るトラフィックフローを調節したり、ネットワークリソースへのアクセスを異なる間のネットワークリソースへのアクセスを仲裁する他の機能などのノードトラフィックコントロール機能が含まれます。パケットまたは異なるトラフィックストリーム間。
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.
インターネットトラフィックエンジニアリングの最適化目標は、単に一度限りの目標としてではなく、ネットワークパフォーマンスの改善の継続的かつ反復プロセスと見なす必要があります。トラフィックエンジニアリングは、ネットワークパフォーマンスの向上のための新しいテクノロジーと新しい方法論の継続的な開発も要求しています。
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.
インターネットトラフィックエンジニアリングのもう1つの重要な側面は、ネットワークパフォーマンス評価です。これは、トラフィックエンジニアリング方法の有効性を評価し、ネットワークパフォーマンスの目標を監視および検証するために重要です。パフォーマンス評価の結果を使用して、既存の問題を特定し、ネットワークの再最適化をガイドし、潜在的な将来の問題の予測に役立ちます。
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]などの概念を簡素化することを使用して、パケットレベルで節点の挙動を近似し、接続レベルで分析を簡素化できます。たとえば、漸近および分解技術に基づいたキューイングモデルと近似スキームを使用したネットワーク分析手法により、分析をさらに扱いやすくする可能性があります。特に、決定論的境界に基づいたネットワーク計算[Cruz]として知られる新しい一連の概念セットは、古典的な確率的手法と比較してネットワーク分析を簡素化する可能性があります。分析手法を使用する場合、モデルがモデル化されたネットワークエンティティの関連する運用特性を忠実に反映するように注意する必要があります。
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メトリックの操作に基づくトラフィックエンジニアリングは、詳細に対処されていません。このトピックは、他のワーキンググループドキュメントによって対処される場合があります。
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.
- Bottleneck：入力トラフィックレートが出力率よりも大きくなる傾向があるネットワーク要素。
- 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.
- ドメイン間トラフィック：ある自律システムで発生し、別のシステムで終了するトラフィック。
- 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.
- トラフィック強度：指定された期間にわたるリソース容量に関するトラフィックロードの尺度。古典的なテレフォニーシステムでは、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ネットワークは、次のことで構成される分散動的システムとして表現できます。ネットワークを介して輸送される提供された負荷を表し、（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.
ネットワーク要素とリソースには、需要が処理される方法を制限する特定の特性がある場合があります。さらに、ネットワークリソースには、需要が整備される方法を監督するトラフィック制御メカニズムが装備されている場合があります。たとえば、トラフィックコントロールメカニズムを使用して、特定のリソース内のさまざまなパケット処理アクティビティを制御し、異なるパケットによるリソースへのアクセスのための任意の競合、およびリソースを介してトラフィックの動作を規制する場合があります。構成管理およびプロビジョニングシステムにより、ネットワーク要素が内部および外部刺激に応答する方法を制御するために、トラフィック制御メカニズムの設定を外部または内部エンティティによって操作できる場合があります。
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.
現代のインターネットネットワークには3つの重要な特性があります。（1）リアルタイムサービスを提供し、（2）ミッションクリティカルになり、（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]の出現により、この要件は特に深刻になります。したがって、各動作集合体には、行動特性の共通セットまたは共通の配信要件セットがあるように、パケットを動作集合体にグループ化できます。実際には、特定のパケットセットの配信要件が明示的または暗黙的に指定される場合があります。最も重要なトラフィック配信要件の2つは、容量の制約と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要件は、（1）各パケットの配信（遅延）のタイミング制限などの時間的制約と、に属する連続したパケットの配信のタイミング制限などの時間的制約の観点から、（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.
さらに別のクラスの問題は、ネットワークの状態を特徴付ける方法と、さまざまなシナリオの下でそのパフォーマンスを評価する方法に関するものです。パフォーマンス評価の問題は2つあります。この問題の1つの側面は、ネットワークのシステムレベルのパフォーマンスの評価に関連しています。他の側面は、リソースレベルのパフォーマンスの評価に関連しており、個々のネットワークリソースのパフォーマンス分析への注意を制限します。このメモでは、ネットワークのシステムレベル特性を「マクロステート」と呼び、リソースレベルの特性を「マイクロステート」と呼びます。システムレベルの特性は、前述のように、ネットワークの緊急プロパティとしても知られています。それに対応して、システムレベルでのネットワークパフォーマンスの最適化を扱うトラフィックエンジニアリングスキームを「マクロテ」と呼び、個々のリソースレベルで最適化するスキームを「マイクロテ」と呼びます。特定の状況では、システムレベルのパフォーマンスは、特定の関心のあるパフォーマンス測定に応じて、適切な構成ルールを使用してリソースレベルのパフォーマンスから導き出すことができます。
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コンテキストで最も重要な問題の1つです。ネットワーク要素は、時間間隔で持続的な過負荷を経験した場合、混雑していると言われています。混雑は、ほとんどの場合、エンドユーザーにサービス品質を低下させます。混雑制御スキームには、需要側のポリシーと供給側のポリシーを含めることができます。需要側のポリシーは、混雑したリソースへのアクセスを制限し、/または過負荷の状況を軽減するために需要を動的に規制する場合があります。供給側のポリシーは、提供されたトラフィックに適しているため、ネットワーク容量を拡大または増強する場合があります。供給側のポリシーは、インフラストラクチャ上のトラフィックを再配布することにより、ネットワークリソースを再割り当てする場合があります。トラフィックの再配布とリソースの再配分は、需要に見られる「効果的な能力」を高めるのに役立ちます。
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) ネットワークのパフォーマンス評価、パフォーマンスの最適化、パフォーマンスの改善に関する一連のガイドライン。
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ネットワークのルーティングは、BGP属性の操作やIGPメトリックの操作など、さまざまなレベルの抽象化で管理上制御できます。MPLSなどのパス指向テクノロジーの場合、関連するトラフィックエンジニアリングパラメーター、リソースパラメーター、および管理ポリシーの制約の操作により、ルーティングをさらに制御できます。MPLSのコンテキスト内で、明示的なラベルスイッチ付きパス（LSP）のパスは、次のようなさまざまな方法で計算および確立できます。（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- 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].
- 短い（ピコ秒から分）：このカテゴリには、いくつかの往復時間の順序でのパケットレベルの処理機能とイベントが含まれます。パッシブやアクティブバッファー管理などのルーターメカニズムが含まれています。これらのメカニズムは、輻輳および/または輻輳を制御してシステムを終了させるために使用され、トラフィックがネットワークに注入される速度を適応的に調節できるようにします。最も人気のあるアクティブキュー管理スキームの1つは、特にTCPトラフィックの場合、ランダムな早期検出（RED）[FLJA93]です。これは、平均キューサイズを制御することにより混雑回避をサポートします。輻輳中（ただし、キューが充填される前）に、赤いスキームは、平均キューサイズを考慮した確率的アルゴリズムに従って「マーク」するパケットを選択します。明示的なうっ血通知を使用しないルーター（ECN）の場合、[Floy94]を参照すると、マークされたパケットを単純にドロップして、輻輳の開始システムから終了システムの開始を知らせることができます。一方、ルーターがECNをサポートする場合、PacketヘッダーにECNフィールドを設定できます。マルチクラス環境[RFC-2597]、たとえば赤の内外（リオ）と重み付き赤で異なるドロップの優先順位レベルをサポートするために、赤のいくつかのバリエーションが提案されています。Redが輻輳回避性能を提供するという一般的なコンセンサスがあります。これは、従来のテールドロップ（TD）キュー管理よりも悪くない（キューがいっぱいの場合にのみ到着するパケットを落とす）。しかし、重要なことに、赤はグローバルな同期の可能性を減らし、異なるTCPセッションの間で公平性を向上させることです。ただし、赤自体は、UDPトラフィックやいくつかの誤った貪欲なつながりなど、赤に反応しないソースによって引き起こされる混雑や不公平を防ぐことはできません。反応のないトラフィックの存在下でのパフォーマンスと公平性を改善するために、他のスキームが提案されています。これらのスキームのいくつかは、理論的枠組みとして提案されており、通常、既存の商用製品では利用できません。このような2つのスキームは、最長キュードロップ（LQD）とランダムドロップ（RND）による動的ソフトパーティション化[SLDC98]です。
(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.
- 予防：予防（予測/回避）ポリシーは、将来の潜在的な混雑問題の推定と予測に基づいて輻輳を防ぐために積極的な行動を起こします。長時間および中型のスケールで説明されているポリシーのいくつかは、このカテゴリに分類されます。彼らは必ずしも既存の混雑の問題にすぐに反応するわけではありません。代わりに、トラフィックの需要とワークロードの分布の予測が考慮され、将来の潜在的な混雑の問題を防ぐために行動が取られる場合があります。短い時間スケール（赤とそのバリエーション、ECN、LQD、およびRNDなど）で説明されているスキームは、キューが実際にオーバーフローする前にパケットをドロップまたはマークするため、混雑回避にも使用されます。
(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.
- 需要側：需要側の輻輳管理ポリシーは、渋滞の問題を軽減するために提供されるトラフィックを管理または規制します。たとえば、前述の短い時間スケールメカニズムのいくつか（赤とそのバリエーション、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目標を達成および維持するために、修正または完全なアクションを測定および適用することが含まれます。
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.
プロセスモデルの第2フェーズは、運用ネットワークからの測定データの取得を含むフィードバックメカニズムです。ネットワークから経験的なデータが容易に利用できない場合、代わりに合成ワークロードを使用して、ネットワークの予想されるワークロードまたは予想されるワークロードのいずれかを反映できます。合成ワークロードは、以前の経験的データを使用した推定または外挿によって導出される場合があります。それらの導出は、トラフィック特性またはその他の手段の数学的モデルを使用して取得することもできます。
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プロセスモデルの第4フェーズは、ネットワークのパフォーマンス最適化です。パフォーマンス最適化フェーズには、一連の代替案から一連のアクションを選択および実装する決定プロセスが含まれます。最適化アクションには、提供されるトラフィックを制御するか、ネットワーク全体のトラフィックの分布を制御するための適切な手法の使用が含まれる場合があります。また、最適化アクションには、リンクの追加またはリンク容量の増加、ルーターやスイッチなどの追加のハードウェアの展開、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].
前述のように、ネットワークパフォーマンスの最適化は継続的なプロセスです。パフォーマンスの最適化イテレーションは、リアルタイム最適化サブプロセスと非リアルタイムネットワーク計画サブプロセスで構成されている場合があります。リアルタイムの最適化とネットワーク計画の違いは、主に動作する相対的なタイムスケールとアクションの粒度にあります。リアルタイムの最適化サブプロセスの目的の1つは、既存のネットワークインフラストラクチャ上のトラフィックのマッピングと分布を制御して、混雑を回避および/または緩和するために、満足のいくサービス提供を保証し、リソースの利用を最適化することです。ネットワークの設計に関係なく、ファイバーの削減や交通需要のシフトなどのランダムなインシデントが発生するため、リアルタイムの最適化が必要です。これらのインシデントは、混雑やその他の問題を運用上のネットワークで明らかにする可能性があります。リアルタイムの最適化は、マイクロ秒から数分または時間までの範囲の小規模から中程度の時間スケールでこのような問題を解決する必要があります。リアルタイムの最適化の例には、キュー管理、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.
ネットワーク計画サブプロセスの機能の1つは、ネットワークのアーキテクチャ、テクノロジー、トポロジ、および容量を体系的に進化させるためのアクションを開始することです。ネットワークに問題が存在する場合、リアルタイムの最適化は即時の救済を提供するはずです。迅速な応答が必要なため、リアルタイムソリューションは可能な限り最良のソリューションではない場合があります。その後、ソリューションを改善し、状況を改善するためにネットワーク計画が必要になる場合があります。ネットワーク計画は、交通量の増加と交通量の変化を長期にわたってサポートするためにネットワークを拡張するためにも必要です。前述のように、ネットワークのトポロジおよび/または容量の変更は、ネットワーク計画の結果である可能性があります。
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。Ash[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.
初期の電話ネットワークは静的な階層的ルーティングに依存していたため、ルーティングパターンは、ネットワークまたは時刻の状態とは無関係に固定されたままでした。階層は、オーバーフロートラフィックに対応し、代替ルートを介してネットワークの信頼性を改善し、厳格な階層ルールを使用してコールループを防ぐことを目的としていました。特定の固定ルートを寸法化する必要があり、忙しい1日の忙しい時間にユーザーのトラフィックを運ぶことができるため、ネットワークは通常、過剰に生成されました。テレフォニーネットワーク内の階層的ルーティングは、より複雑なトラフィックエンジニアリングルールを管理できるデジタルスイッチと保存されたプログラム制御の出現により、硬すぎることがわかりました。
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％減少させます（静的階層ルーティングと比較して）。動的なルーティングは、ルートを1コールごとに再計算し、定期的にルートを更新することにより、ネットワークの回復力を向上させることもできます。
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.
時間依存ルーティングでは、事前に計画されたルーティングテーブルでは、交通負荷の定期的な変動（時間の時間や曜日など）が活用されています。状態依存ルーティングでは、ルーティングテーブルは、ネットワークの現在の状態（たとえば、トラフィック需要、利用など）に従ってオンラインで更新されます。依存ルーティングの場合、ルーティングの変更は、学習モデルを使用して新しいパスが検索されるイベント（混雑したリンクまたはブロックされたリンクに遭遇するコールセットアップなど）によって受け入れられます。EDRメソッドはリアルタイムの適応型ですが、SDRと同様にグローバルな状態情報を必要としません。EDRスキームの例には、BTからの動的な代替ルーティング（DAR）、NTTからの状態および時間依存ルーティング（STR）、および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 Tollネットワークで導入された動的ルーティングの例であり、時間の関数などの通常の負荷変動などの時間依存情報に応答します。負荷に関する時間依存情報は、1時間ごと、毎週、および毎年の3つの時間スケールに分割される場合があります。それに対応して、3つのアルゴリズムが定義されており、ルーティングテーブルを事前に計画します。ネットワーク設計アルゴリズムは1年間の間隔で動作しますが、需要サービスアルゴリズムは毎週動作し、リンクサイズとルーティングテーブルを微調整して、年間予測エラーを修正します。最小のタイムスケールでは、ルーティングアルゴリズムを使用して、毎日のトラフィックの変動に基づいて限定的な調整を行います。ネットワーク設計と需要サービスは、オフライン計算を使用して計算されます。通常、計算では、可能なルートで広範な検索が必要です。一方、ルーティングはクランクバックを処理するためにオンライン計算が必要になる場合があります。DNHRは、パスがせいぜい2つのリンクで構成できる「2つのリンク」アプローチを採用しています。ルーティングアルゴリズムは、発信スイッチと終端スイッチの間のルート選択の順序付けられたリストを提示します。コールがオーバーフローする場合、viaスイッチ（発信スイッチと終端スイッチ間のタンデム交換）は、クランクバック信号を発信スイッチに送信します。このスイッチは、コールがブロックされる代替ルートが利用できないまで、次のルートなどを選択します。
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.
初期のアーパネットは、ルーティングの決定がネットワークの現在の状態に基づいている適応ルーティングの重要性を認識しました[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.
このアプローチの1つの欠点は、動的リンクメトリックが「トラフィックマグネット」を作成する傾向があることです。これにより、渋滞がネットワークのある場所から別の場所に移動し、振動とネットワークの不安定性が生じます。
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:
静的リンクメトリックの割り当ては不十分であることが明らかになりました。なぜなら、それはいくつかのリンクが混雑している間、他のリンクが軽くロードされたままになる不利なシナリオに簡単につながる可能性があるためです。静的リンクメトリックの不十分さの多くの理由の1つは、ネットワーク内のトラフィックマトリックスを考慮せずにリンクメトリック割り当てが行われたことです。また、ルーティングプロトコルは、ルーティングの決定を行う際にトラフィック属性と容量の制約を考慮しませんでした。これにより、交通濃度がネットワークインフラストラクチャのサブセットに局在し、潜在的に渋滞を引き起こすことになります。リンクメトリックがトラフィックマトリックスに従って割り当てられている場合でも、次のような数の要因により、ネットワーク内の不均衡な負荷が発生する可能性があります。
- 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などの明示的なルーティングと制約ベースのルーティング機能を備えたパス指向テクノロジーへの関心を動機付ける要因の1つです。
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ごとに最短パスアルゴリズムを実行する必要があり、非常に高価な計算が行われます。IPヘッダーフィールドがDiffServフィールドに置き換えられたため、クラシックTOSベースのルーティングは時代遅れになりました。各クラスは、ネットワーク内の交通濃度のローカリゼーションをもたらす最短パスルーティングにのみ依存しているため、クラシック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]で欠陥に対処しようとするもう1つの手法です。古典的なSPFアルゴリズムでは、特定の宛先に2つ以上の最短パスが存在する場合、アルゴリズムはそれらの1つを選択します。アルゴリズムはECMPでわずかに変更されているため、2つ以上のコストの最短パスが2つのノードの間に存在する場合、ノード間のトラフィックが複数の等コストパスに分散されます。通常、等しいコストのパスを横切るトラフィック分布は、通常、2つの方法のいずれかで実行されます。（1）ラウンドロビンの様式でのパケットベース、または（2）ソースおよび宛先IPアドレスおよび場合によっては他のフィールドでのハッシュを使用してフローベースIPヘッダー。2番目のアプローチはフローの数と分布に依存し、最初のアプローチはオーダーアウト外のパケットを簡単に引き起こす可能性があります。フローベースの負荷共有は、フローの数が比較的小さく、不均一ではないエンタープライズネットワークで予測不可能な場合があります（たとえば、ハッシュは均一ではない場合があります）が、一般的にフローの数が大きいコアパブリックネットワークで効果的ですそして不均一。
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つの等しいコストのパスを考えると、1つのパスが他のパスよりも混雑する可能性があります。ECMPのもう1つの欠点は、非同一コストを持つ複数のパスで負荷共有を達成できないことです。
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.
Nimrodは、複数の制約を考慮しながら、インターネットで不均一なサービス固有のルーティングを提供するために開発されたルーティングシステムです[RFC-1992]。基本的に、Nimrodは、パス指向のパケット転送をサポートするリンク状態ルーティングプロトコルです。マップの概念を使用して、複数のレベルの抽象化でネットワーク接続とサービスを表します。ルーティング情報の分布の制限を可能にするために、メカニズムが提供されます。
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.
Nimrodはパブリックインターネットでの展開を享受していませんでしたが、Nimrodアーキテクチャに組み込まれた多くの重要な概念は、ノードの発信部でパスの選択を可能にする明示的なルーティングなど、最近の制約ベースのルーティングイニシアチブでアプリケーションを見つけ始めています。
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ネットワークを介して仮想回路によって採取された物理的ルートとは無関係に、自分自身の間の直接的な隣接を確認します。したがって、オーバーレイモデルは、RouterがATM、フレームリレー、またはWDMネットワークが管理する物理トポロジから見る論理トポロジを本質的に切り離します。ATMまたはフレームリレーに基づいたオーバーレイモデルにより、ネットワーク管理者またはオートマトンがトラフィックエンジニアリングの概念を採用して、仮想回路を再構成または再配置することによりパス最適化を実行できるようにし、混雑または最適な物理リンクの仮想回路を使用することで、パス最適化を実行できます。あまり混雑またはより最適なものに再ルーティングされます。オーバーレイモデルでは、トラフィックエンジニアリングも採用されており、仮想回路技術のトラフィック管理パラメーター（たとえば、PCR、SCR、およびMBSのMBS、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ルーティング（たとえば、[RFC-2386]および[MA]を参照）とは異なり、通常、個々のトラフィックフローをルーティングする問題に対処し、ネットワークリソースの可用性を条件として所定のフローベースのQoS要件を満たすことができます。流れと同様に、政策制限を含む可能性のあるさまざまな制約があります。
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 Integrated Services Working Groupは、Integrated Services（INTSERV）モデルを開発しました。このモデルには、帯域幅やバッファーなどのリソースに、特定のトラフィックフローの先験的なリソースを確保し、トラフィックフローによって要求されるサービスの品質が満たされるようにします。統合サービスモデルには、パケット分類器、パケットスケジューラ、アミズミコントロールなどのベストエフォルトモデルで使用されるコンポーネントを超えた追加のコンポーネントが含まれています。パケット分類器は、特定のレベルのサービスを受信するフローを識別するために使用されます。パケットスケジューラは、QoSコミットメントが満たされていることを確認するために、さまざまなパケットフローへのサービスのスケジューリングを処理します。入学制御は、ルーターが新しいフローを受け入れるために必要なリソースを持っているかどうかを判断するために使用されます。
Two services have been defined under the Integrated Services model: guaranteed service [RFC-2212] and controlled-load service [RFC-2211].
2つのサービスが統合サービスモデルで定義されています：保証サービス[RFC-2212]と制御されたサービス[RFC-2211]。
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.
統合サービスモデルの注目すべき機能は、エンドシステムからルーターへのQoS要件の明示的なシグナル伝達が必要であることです[RFC-2753]。リソース予約プロトコル（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では、送信者またはソースノードは、送信者が生成するトラフィックと同じソースと宛先アドレスを持つレシーバーにパスメッセージを送信します。パスメッセージには以下が含まれます。（1）トラフィックの特性を指定する送信者TSPEC、（2）トラフィックの形式を指定する送信者テンプレート、および（3）広告で1つのパスの概念をサポートするために使用されるオプションのADSPEC"（OPWA）[RFC-2205]。パスに沿った中間ルーターはすべて、パスメッセージをルーティングプロトコルによって決定される次のホップに向かって前に進みます。パスメッセージを受信すると、レシーバーは、リクエストリソースの予約。RESVメッセージは、パスメッセージが通過するパスに沿って反対方向に送信者またはソースノードに移動します。パスに沿ったすべての中間ルーターは、RESVメッセージの予約要求を拒否または受け入れることができます。リクエストが拒否された場合、拒否ルーターはエラーメッセージを受信機に送信し、信号プロセスが終了します。リクエストが受け入れられると、リンク帯域幅とバッファースペースが流れに割り当てられ、関連するフロー状態情報がルーターにインストールされます。
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仕様の問題の1つは、スケーラビリティでした。これは、ネットワーク要素によって維持される状態の量がマイクロフローの数とともに直線的に増加する傾向があるため、これはマイクロフローに予約が必要だったためです。これらの問題は[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の取り組みの主な動機の1つは、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 Octetとして知られていた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モデルが本質的に交通管理の問題を1ホップごとに扱っていることは明らかです。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ドメインへのイングレスでは、ラベルスイッチングルーター（LSRS）は、IPパケットを、パケットのIPヘッダーに含む情報の組み合わせと、さまざまな要因に基づいて、IPパケットを転送等価クラス（FEC）に分類します。LSRSが維持するローカルルーティング情報。MPLSラベルは、転送等価クラスに従って各パケットに加えられます。非ATM/FR環境では、ラベルの長さは32ビットで、20ビットラベルフィールド、3ビットの実験フィールド（以前はクラスオブサービスまたはCOSフィールドとして知られています）、1ビットラベルスタックが含まれています。インジケータと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とラベル付きパケットが通過する出力LSRの間のパスです。明示的なLSPのパスは、LSPの発信（イングレス）ノードで定義されます。MPLSは、RSVPやLDPなどのシグナル伝達プロトコルを使用してLSPを設定できます。
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].
MPLSは、IPネットワークで制約ベースのルーティングを効率的に実装できる明示的なLSPをサポートするため、インターネットトラフィックエンジニアリングにとって非常に強力なテクノロジーです[AWD2]。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]が含まれます。その他の指標には、パケットの損失と遅延の2次測定が含まれます。
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は、ユーザーとサービスプロバイダーの間で交渉されたサービスレベルの目標セットであり、各目標は、特定の制約の対象となる可能性のある1つ以上のパフォーマンスメトリックの組み合わせです。
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.600は、トラフィックエンジニアリングの概念を説明するための語彙を提供し、e.701はISDNの参照接続、サービスグレード（GOS）、およびトラフィックパラメーターを定義します。推奨事項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
- 時間依存と状態依存対イベント依存 - オフライン対オンライン - 集中vs分散 - ローカルvsグローバル情報 - 規範的vs記述 - オープンループvsクローズドループ - 戦術vs戦略的
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制御メカニズムに使用されます。さらに、顧客のサブスクリプションまたはトラフィック予測を使用する場合があります。事前にプログラムされたルーティングプランは、通常、比較的長い時間尺度（日中）で変更されます。時間依存のアルゴリズムは、トラフィックやネットワーク条件の変化のランダムな変動に適応しようとはしません。時間依存のアルゴリズムの例は、システムへの入力が、説明されているようにトラフィックマトリックスとマルチクラスの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）メソッドのように、モデルを学習することにより容量を検索します。ALB洪水は、LSAを運ぶためにリンク帯域幅、プロセッサ容量がLSAを処理する必要があるため、リソース集中になり、オーバーヘッドはエリア/自律システム（AS）サイズを制限できます。モデリングの結果は、イベント依存のTEメソッドが、ネットワークスループットのパフォーマンスを失うことなく、ALB洪水オーバーヘッドの減少につながる可能性があることを示唆しています[ASH3]。
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 IGPSの等しいコストマルチパス（ECMP）機能は、2つのノード間の等しいコストパス間でトラフィックの共有をサポートします。ただし、ECMPは、トラフィックを可能な限り等しくコストの最短パスで等しく分割しようとします。一般に、ECMPは、等しいコストパス間で構成可能な負荷共有率をサポートしていません。その結果、パスの1つは、他のソースからのトラフィックも運ぶ可能性があるため、他のパスよりも大幅に多くのトラフィックを運ぶ可能性があります。この状況は、より多くのトラフィックを運ぶ経路に沿って渋滞をもたらす可能性があります。
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.
制約ベースのルーティングは、IPネットワークのルーティングアーキテクチャ、特に複雑なトポロジを持つパブリックIPバックボーン[RFC-2702]を進化させるために望ましいです。制約ベースのルーティングは、制約の対象となる要件を満たすためのルートを計算します。制約には、帯域幅、ホップカウント、遅延、およびリソースクラス属性[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やIS-ISなどの従来のリンク状態IGPには、制約ベースのルーティングに必要な追加の状態情報を配布できるようにするために、多くの強化が必要です。これらのOSPFへの拡張は[katz]および[smit]でis-isに記載されています。基本的に、これらの拡張機能には、リンク状態広告に追加情報の伝播が必要です。具体的には、通常のリンク状態情報に加えて、制約ベースのルーティングに必要なトポロジー状態情報を伝播するには、強化されたIGPが必要です。追加のトポロジ状態情報には、予約可能な帯域幅やリンクリソースクラス属性（管理上指定されたリンクのプロパティ）などのリンク属性が含まれます。リソースクラス属性の概念は[RFC-2702]で定義されました。追加のトポロジー状態情報は、IS-ISの新しいTLVおよびサブTLV、またはOSPF [SMIT、KATZ]の不透明LSAで実施されます。
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].
ルーティングシステムには、この目的のために十分なリソースが存在する場合、他のトラフィックのルートに影響を与えることなく、トラフィックのサブセットのルートを制御する機能も備えている必要があります。この機能により、ネットワーク全体のトラフィックの分布をより洗練した制御が可能になります。たとえば、ソースから元のパスから別のパスまで（他のトラフィックパスに影響を与えることなく）トラフィックをソースから目的地に移動する機能により、リソースの貧しいネットワークセグメントからリソースが豊富なセグメントにトラフィックを移動できます。MPLなどのパス指向技術は、[AWD2]で説明したように、本質的にこの機能をサポートしています。
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.
動的な状態フィードバックに依存するトラフィックマッピング手法（たとえば、仲間など）を使用する場合、ネットワークの安定性を保証するために特別な注意を払う必要があります。
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.
交通統計は、長期または短期の時間尺度に従って分類される場合があります。長期の時間尺度トラフィック統計は、交通工学に非常に役立ちます。長期の時間尺度トラフィック統計は、ネットワークワークロードの周期性（交通プロファイルの1時間ごと、毎日、および毎週の変動など）およびトラフィックの傾向をキャプチャまたは反映する場合があります。監視されているトラフィック統計の側面は、複数のクラスのサービスをサポートするネットワークのサービス特性のクラスを描写する場合があります。長期の交通統計の分析により、忙しい時間特性、交通成長パターン、持続的な混雑の問題、ホットスポット、ルーティングの異常によって引き起こされるリンク利用の不均衡などの二次統計が得られる可能性があります。
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.
ネットワークの生存性とは、障害の存在下でサービスの継続性を維持するネットワークの機能を指します。これは、ネットワークの障害から迅速に回復し、回復後に既存のサービスに必要なQOを維持することによって達成できます。ミッションの重要なトラフィック、リアルタイムトラフィック、およびインターネット上のその他の優先度の高いトラフィックを運ぶという要求が増加しているため、インターネットコミュニティ内での生存性は大きな懸念事項となっています。より信頼性の高いネットワーク要素を開発することにより、デバイスレベルで生存性に対処できます。ネットワークのアーキテクチャ、設計、および運用に冗長性を組み込むことにより、ネットワークレベルで。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コンテキストのいくつかの新しい開発により、収束前にIPレイヤーで回復を達成することが可能になります[Shar]。
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.
最近、頭字語Multi-Protocol Lambda Switching [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.
多層の生存性に関するもう1つの重要な側面は、異なる層の技術が、異なる時間的粒度（時間スケールの観点から）および異なる帯域幅の粒度（パケットレベルから波長レベルまで）で保護と回復能力を提供することです。保護および修復機能は、さまざまなサービスクラスやさまざまなネットワークユーティリティモデルにも敏感です。
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.
- 異なる層からの保護と修復機能は、柔軟で費用対効果の高い方法でネットワークの生存性を提供するために、実行可能かつ適切な場合はいつでも調整する必要があります。レイヤー間の関数の複製の最小化は、調整を実現する1つの方法です。アラームのエスカレーションや下層から高層へのその他の断層指標も、調整された方法で実行される場合があります。さまざまなレイヤーでの回復トリガータイミングの時間的順序は、多層保護/修復を調整するもう1つの方法です。
- 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のトラフィックは、失敗したリンクのヘッドエンドで保護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が、イングレスおよび出口LSRで発生する可能性のある障害、または作業パスとバックアップパスの両方に影響を与える可能性のある相関障害を除き、パスに沿ったすべての可能なリンクおよびノード障害から動作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.
考慮すべきもう1つの問題は、保護オプションの概念です。保護オプションは、Notation M：N保護を使用します。ここで、MはN作業LSPを保護するために使用される保護LSPの数です。実行可能な保護オプションが続きます。
- 1:1: one working LSP is protected/restored by one protection LSP.
- 1：1：1つの作業LSPは、1つの保護LSPによって保護/復元されます。
- 1:n: one protection LSP is used to protect/restore n working LSPs.
- 1：N：1つの保護LSPを使用して、動作する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+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は、現地の交通整合性決定プロセスに基づいて2つのLSPのいずれかを選択します。これは、作業LSPと保護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.
このセクションでは、差別化されたサービス（diffserv）[RFC-2475]有能なIPネットワークに特に関連するトラフィックエンジニアリングの機能と推奨事項の概要を説明します。
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メカニズムのcompめ言葉として使用できますが、一般的に必要な要素としてではありません。トラフィックエンジニアリングを使用する場合、すべてのサービスクラス[RFC-3270]で集約されたベースで、またはサービスクラスごとに操作できます。前者は、ネットワークリソース上の総トラフィック負荷のより良い分布を提供するために使用されます。（集約的なトラフィックエンジニアリングをサポートする詳細なメカニズムについては、[RFC-3270]を参照してください。）後者のケースは、いわゆるDiffserv-Aware Traffic Engineering [diff_te]を使用して、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ネットワークの場合、各サービスクラスが貢献したトラフィックワークロードとそのサービスクラスに割り当てられたネットワークリソースの量との間に特定の関係を実施することにより、一部のサービスクラスのパフォーマンスを制御することが望ましい場合があります。需要とリソースの割り当ての間の関係は、例えば次のような組み合わせを使用して実施できます。そのクラスに対して、および（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の両方をサポートするドメインでこれを達成する1つの方法は、クラス固有の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ベースの順序付け集合体の両方を含む低損失クラスタイプです。このようなクラスタイプを使用すると、AF1ベースのトラフィックトランクよりも高いプリエンプションの優先順位をAF2ベースのトランクに割り当てる優先度ポリシーを実装できます。その逆、または同じ優先事項です。
See [DIFF-TE] for detailed requirements on Diffserv-aware traffic engineering.
DiffServ-Aware Traffic Engineeringの詳細な要件については、[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.
制御メカニズムは、手動（管理構成など）、部分的に自動化された（たとえば、スクリプト）、または完全に自動化されます（ポリシーベースの管理システムなど）。大規模なネットワークでは、自動化されたメカニズムが特に必要です。マルチベンダーの相互運用性は、標準化された管理システム（標準MIBSなど）およびポリシー（PIBS）を開発および展開して、負荷分布や保護/修復などのトラフィックエンジニアリングの目標に対処するために必要な制御機能をサポートすることで促進できます。
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つの管理ドメインに由来し、別のドメインで終了するトラフィックのパフォーマンスの最適化に関係しています。
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間のルートの輸入と輸出を制御し、AS内のBGPと他のプロトコル間のルートの再分配を制御します。
- 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決定プロセスに関連付けられた属性を操作することにより影響を受ける可能性があります。これらの属性には、次の属性が含まれます。ネクストホップ、重量（他のいくつかのベンダーによっても実装されているシスコ専有）、ローカルプレーファレンス、パス、ルートオリジン、マルチエキシットデスクリミネーター（MED）、IGPメトリックなどが含まれます。
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ピアからインバウンドトラフィックが受信される相互接続ポイントは通常、特別な取り決めが行われない限り、そうではないことに注意する必要があります。交通を送るピア。したがって、顧客からピアリングポイントへのアウトバウンドトラフィックの効率的な配信を扱うサウンドTE戦略を実装するのは、個々のネットワーク次第です。TEポリシーの大部分は、「最も近い出口」戦略に基づいており、宛先自律システムに向かって最も近いアウトバウンドピアポイントでドメイン間トラフィックをオフロードします。インバウンドトラフィックがEBGPピアからネットワークに入るポイントを操作するほとんどの方法（Peering Points、Pre-Pending、およびSending Medの間の一貫性のあるルートの発表）は、ピアリングコミュニティでは効果がないか、受け入れられません。
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つのドメインが別のドメインがネットワーク内のトラフィックのルーティングと管理に影響を与えることは、一般的には積極的ではないと考えられます。
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-TUNNELS（明示的なLSP）は、ドメイン間ルーティングの出口ポイントの選択にある程度の柔軟性を追加する可能性があります。相対的および絶対的なメトリックの概念は、この目的に適用できます。アイデアは、BGP属性が定義されている場合、BGP決定プロセスがIGPメトリックに依存してドメイン間トラフィックの出口ポイントを選択すると、特定のピアネットワークに運命づけられているドメイン間トラフィックを特定するために、特定の出口ポイントを好むことができるということです。ルーター間にTEトンネルを確立し、TEトンネルを介してピアリングポイントに選択を行い、TE-Tunnel Aを他のすべてのピアリングポイントにコストよりも小さいメトリックに割り当てることにより。ピアがMEDを受け入れて処理する場合、同様のMPLS TE-Tunnelベースのスキームを適用して、MEDをIGPコストに設定することにより、トンネルメトリックによって変更されたIGPコストを設定することにより優先されるようにすることができます。
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.
一般に、ドメイン間トラフィックの再分配には、ピアリングパートナー間の調整が必要です。別のドメインを使用してピアポイント全体で負荷の再分配をもたらす1つのドメインのエクスポートポリシーは、ピアリングパートナーのドメイン内のローカルトラフィックマトリックスに大きく影響する可能性があります。これは、トラフィックの空間分布の変化により、ドメイン内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.
通常、運用ネットワークのパフォーマンスの最適化は、トラフィック統計、パフォーマンスパラメーター、および障害インジケーターがネットワークから継続的に収集される継続的なプロセスです。次に、この経験的データを分析し、さまざまなトラフィックエンジニアリングメカニズムをトリガーするために使用されます。What-IF分析を実行するツールは、運用ネットワークに新しい構成セットが実装される前に、さまざまなシナリオをレビューできるようにすることにより、TEプロセスを支援するために使用できます。
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またはIS-I-I-I-I-I-ISメトリックを増やすことにより行われます。このアプローチには、セクション6.2で説明したようにいくつかの制限があります。最近、いくつかの新しいドメインTEアプローチ/ツールが提案されています[RR94] [FT00] [FT01] [Wang]。このようなアプローチ/ツールは、トラフィックマトリックス、ネットワークトポロジ、ネットワークパフォーマンスの目標を入力として取り、いくつかのリンクメトリックと、一部のECMPのヘッドエンドルーターに設定するリンクメトリックと、おそらく不均等な負荷シェアリング比を生成します。これらの新しい進歩は、より体系的な方法で行われる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]。MPLSおよびルーターハードウェアテクノロジーの最近の進歩により、ATM上の技術はもはや好意的には見られません。
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の展開は、一部のサービスプロバイダーネットワークで開始されています。運用シナリオの1つは、明示的なルート計算のための制約ベースのルーティングと合わせてトラフィックエンジニアリング拡張をサポートするIGP（IS-IS-TEまたはOSPF-TE）と組み合わせてMPLを展開することです。-teまたはcrldp）lspインスタンス化用。
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.
相互接続の場所が決定され、回路が実装されると、ピアから聞いたルートをどのように処理するか、自分のネットワーク内のピアのルートを伝播する方法を決定します。多くのEBGPピアとのネットワーク上のアウトバウンドトラフィックフローを設計する1つの方法は、ピアの階層を作成することです。一般的に、すべてのピアのローカルな選好は同じ値に設定されているため、パスが最も短いものがトラフィックを転送するために選択されます。次に、インバウンドMEDメトリック（「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.
インバウンドMEDメトリックをBGPメトリックに置き換えることにより、等しいAS-PATH長いルートの出口ポイントのみが変更されています。（BGPの決定は、最初に現地の好みを、次にパスの長さ、次にBGPメトリックを考慮します）。たとえば、ネットワークにはピアAとピアBの2つの出力ポイントがあると仮定します。各ピアはインターネットのルートの40％をネットワーク上にありますが、インターネットのルートの残りの20％は、AとAとAの間のデュアルホームからのものです。B.両方のピアの局所選好が200とBGPメトリックが100のと仮定します。ピアAへのリンクが混雑している場合、BGPメトリックを増加させながら200の局所選好を残すことで、総ルートの20％がデュアルホームの顧客は、出口ポイントとしてピア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.
特定のピアに複数の出口ポイントがあり、そのうちの1つだけが混雑している場合、交通を完全にピアから遠ざける必要はありませんが、1つの混雑した回路からのみシフトする必要はありません。これは、パッシブ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）を使用することの利点を実現できますが、地域ネットワークの運用の利点も利用できます。これを行う代わりには、異なる地域で異なる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.
著者は、推奨事項の入力についてJim Boyleに感謝したいと思います。FrancoisLeFaucheurは、Diffservの側面に関する入力、測定に関する入力、電話ネットワークでのルーティングの入力、イベント依存TEメソッドのテキストについてはGerald Ash、ネットワーク制御性に関するインプットについてはスティーブンライト、およびBGPを使用したドメイン間TEの入力については、Jonathan Aufderheide。「戦術と戦略的」方法に基づいてTE分類法を提案してくれたRandy Bushに感謝します。「トラフィックエンジニアリングに関連するITUアクティビティの概要」を説明するサブセクションは、Waisum Laiによる貢献から採用されました。関連資料への有用なフィードバックとポインターは、J。NoelChiappaによって提供されました。最後のコールプロセス中に、Glenn Grotefeldによって追加のコメントが提供されました。最後に、著者は、Tewgの共同議長であるEd Kernにコメントとサポートに感謝したいと思います。
[ASH2] J. Ash, Dynamic Routing in Telecommunications Networks, McGraw Hill, 1998.
[ASH2] J. Ash、Telecommunications Networksの動的ルーティング、McGraw Hill、1998。
[ASH3] Ash, J., "TE & QoS Methods for IP-, ATM-, & TDM-Based Networks", Work in Progress, March 2001.
[Ash3] Ash、J。、「IP、ATM、およびTDMベースのネットワークのTE＆QOSメソッド」、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、「マルチプロコトールラムダスイッチング：MPLSトラフィックエンジニアリングコントロールと光クロスコネクトを組み合わせる」、IEEE Communications Magazine、2001年3月。
[AWD2] D. Awduche, "MPLS and Traffic Engineering in IP Networks", IEEE Communications Magazine, Dec. 1999.
[AWD2] D. Awduche、「IPネットワークのMPLSおよびトラフィックエンジニアリング」、IEEE Communications Magazine、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 et al、「インターネット内の自律システム間の最適なピアリングへのアプローチ」、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. Cruz、「ネットワーク遅延のための計算、パートII：ネットワーク分析」、IEEE情報に関するトランザクション、Vol。37、pp。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] 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、「Diff-Serv-Aware MPLS Traffic Engineeringのサポートの要件」、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。Mitra、R.H。ウェントワース、「ATMノードの不均一で規制されたトラフィックにバッファと帯域幅を割り当てるための新しいアプローチ」、Communicationsの選択された領域に関するIEEE IEEEジャーナル、13：6、pp。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. Feldmann、A。Greenberg、C。Lund、N。Reingold、およびJ. Rexford、「Netscope：IP Networksのトラフィックエンジニアリング」、IEEE Network Magazine、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. FloydおよびV. Jacobson、「混雑回避のためのランダムアーリー検出ゲートウェイ」、IEEE/ACMトランザクションに関するネットワーキング、Vol。11月1日。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. Floyd、「TCPおよび明示的な混雑通知」、ACMコンピューター通信レビュー、V。24、No。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 Weightsを最適化することによるインターネットトラフィックエンジニアリング」、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、「変化する世界でOSPF/IS-ISウェイトの最適化」、www.research.att.com/~mthorup/papers/papers.html。
[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 Communication Magazine、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.、Editior、Andersson、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] Katz、D.、Yeung、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. Lakshman、A。Neidhardt、およびT. Ott、「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. Ma、「統合サービスネットワークの品質ルーティング」、PhD論文、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。Jin、S。Low、およびI. Widjaja、「Mate：MPLS Adaptive Traffic Engineering」、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] J.M. McQuillan、I。Richer、およびE.C. Rosen、「Arpanetの新しいルーティングアルゴリズム」、IEEE。トランス。Communications、vol。28、いいえ。5、pp。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.Ramakrishnan、「データネットワークのマルチサービス、マルチプレイリティトラフィックエンジニアリング設計の事例研究」、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. Li、「A Border Gateway Protocol 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] Baker、F。、「IPバージョン4ルーターの要件」、STD 4、RFC 1812、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、「Nimrod Routing Architecture」、RFC 1992、1996年8月。
[RFC-1997] Chandra, R., Traina, P. and T. Li, "BGP Community Attributes", RFC 1997, August 1996.
[RFC-1997] Chandra、R.、Traina、P。and T. Li、「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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、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.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、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] Moy、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] Paxson、V.、Almes、G.、Mahdavi、J。およびM. Mathis、「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] Crawley、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、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. Paxson、「接続性を測定するための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.、Malcolm、J.、Agogbua、J.、O'dell、M.、J。McManus、「MPLS上のトラフィックエンジニアリングの要件」、RFC 2702、1999年9月。
[RFC-2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RFC-2722] Brownlee、N.、Mills、C。and G. Ruth、「トラフィックフロー測定：アーキテクチャ」、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。and R. Guerin、「政策ベースの入場管理の枠組み」、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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。and 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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。and J. and J.E. Felstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、RFC 2998、2000年11月。
[RFC-3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC-3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Nichols、K。およびB. Carpenter、「ドメインの動作とその仕様の規則ごとの差別化されたサービスの定義」、RFC 3086、2001年4月。
[RFC-3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC-3124] Balakrishnan、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：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.、Hannan、A。、およびX. Xiao、「LSP-Tunnelsの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] Ash、J.、Girish、M.、Gray、E.、Jamoussi、B。およびG. Wright、「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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaahanen、P.、Krishnan、R.、Cheval、P.、J。Heinanen、Multi-Protocol Label差別化されたサービスの切り替え（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. Rodrigues and K.G.Ramakrishnan、「最短経路ネットワークでの最適ルーティング」、ITS'94、Rio de Janeiro、ブラジル。
[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] Sharma、V.、Crane、B.、Owens、K.、Huang、C.、Hellstrand、F.、Weil、J.、Anderson、L.、Jamoussi、B.、Cain、B.、Civanlar、S.およびA. Chui、「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. Suter、T。Lakshman、D。Stiliadis、およびA. Choudhury、「Flow QueuingでTCPをサポートするための設計上の考慮事項」、Proc。Infocom'98、p。299-306、1998。
[SMIT] Smit, H. and T. Li, "IS-IS extensions for Traffic Engineering", Work in Progress.
[Smit] Smit、H。およびT. Li、「トラフィックエンジニアリングの拡張機能」、進行中の作業。
[WANG] Y. Wang, Z. Wang, L. Zhang, "Internet traffic engineering without full mesh overlaying", Proceedings of INFOCOM'2001, April 2001.
[Wang] Y. Wang、Z。Wang、L。Zhang、「完全なメッシュオーバーレイなしのインターネットトラフィックエンジニアリング」、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. Xiao、A。Hannan、B。Bailey、L。Ni、「インターネットでMPLSを使用した交通工学」、IEEE Network Magazine、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. Yang and A. Reddy、「パケットスイッチングネットワークにおける混雑制御アルゴリズムの分類法」、IEEE Network Magazine、p。34-45、1995。
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive、Suite 615 McLean、VA 22102
Phone: 703-298-5291 EMail: awduche@movaz.com
電話：703-298-5291メール：awduche@movaz.com
Angela Chiu Celion Networks 1 Sheila Dr., Suite 2 Tinton Falls, NJ 07724
アンジェラチウセリオンネットワーク1シーラ博士、スイート2ティントンフォールズ、ニュージャージー07724
Phone: 732-747-9987 EMail: angela.chiu@celion.com
電話：732-747-9987メール：angea.chiu@celion.com
Anwar Elwalid Lucent Technologies Murray Hill, NJ 07974
Anwar Elwalid Lucent Technologies Murray Hill、NJ 07974
Phone: 908 582-7589 EMail: anwar@lucent.com
電話：908 582-7589メール：anwar@lucent.com
Indra Widjaja Bell Labs, Lucent Technologies 600 Mountain Avenue Murray Hill, NJ 07974
Indra Widjaja Bell Labs、Lucent Technologies 600 Mountain Avenue Murray Hill、NJ 07974
Phone: 908 582-0435 EMail: iwidjaja@research.bell-labs.com
電話：908 582-0435メール：iwidjaja@research.bell-labs.com
XiPeng Xiao Redback Networks 300 Holger Way San Jose, CA 95134
Xipeng Xiao Redback Networks 300 Holger Way San Jose、CA 95134
Phone: 408-750-5217 EMail: xipeng@redback.com
電話：408-750-5217メール：xipeng@redback.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。