Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 9522 Old Dog Consulting
Obsoletes: 3272 January 2024
Category: Informational
ISSN: 2070-1721
This document 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 the networks that support IP networking 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 networks are also discussed.
このドキュメントでは、インターネット内の交通工学の原則（TE）について説明しています。このドキュメントは、IPネットワークのトラフィックエンジニアリングを取り巻く問題と、IPネットワークをサポートするネットワークをよりよく理解し、インターネットのトラフィックエンジニアリング機能の開発に共通の基礎を提供することを目的としています。運用ネットワークのパフォーマンス評価とパフォーマンスの最適化のための原則、アーキテクチャ、および方法論についても説明します。
This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF.
この作業は、2002年5月にRFC 3272として最初に公開されました。このドキュメントは、RFC 3272を廃止し、インターネットトラフィックエンジニアリングの最良の現在のプラクティスに並んでテキストを導入し、IETFでの最新の関連する作業への参照を含めることにより。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9522.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9522で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. What is Internet Traffic Engineering?
1.2. Components of Traffic Engineering
1.3. Scope
1.4. Terminology
2. Background
2.1. Context of Internet Traffic Engineering
2.2. Network Domain Context
2.3. Problem Context
2.3.1. Congestion and Its Ramifications
2.4. Solution Context
2.4.1. Combating the Congestion Problem
2.5. Implementation and Operational Context
3. Traffic-Engineering Process Models
3.1. Components of the Traffic-Engineering Process Model
4. Taxonomy of Traffic-Engineering Systems
4.1. Time-Dependent versus State-Dependent versus
Event-Dependent
4.2. Offline versus Online
4.3. Centralized versus Distributed
4.3.1. Hybrid Systems
4.3.2. Considerations for Software-Defined Networking
4.4. Local versus Global
4.5. Prescriptive versus Descriptive
4.5.1. Intent-Based Networking
4.6. Open-Loop versus Closed-Loop
4.7. Tactical versus Strategic
5. Review of TE Techniques
5.1. Overview of IETF Projects Related to Traffic Engineering
5.1.1. IETF TE Mechanisms
5.1.2. IETF Approaches Relying on TE Mechanisms
5.1.3. IETF Techniques Used by TE Mechanisms
5.2. Content Distribution
6. Recommendations for Internet Traffic Engineering
6.1. Generic Non-functional Recommendations
6.2. Routing Recommendations
6.3. Traffic Mapping Recommendations
6.4. Measurement Recommendations
6.5. Policing, Planning, and Access Control
6.6. Network Survivability
6.6.1. Survivability in MPLS-Based Networks
6.6.2. Protection Options
6.7. Multi-Layer Traffic Engineering
6.8. Traffic Engineering in Diffserv Environments
6.9. Network Controllability
7. Inter-Domain Considerations
8. Overview of Contemporary TE Practices in Operational IP
Networks
9. Security Considerations
10. IANA Considerations
11. Informative References
Appendix A. Summary of Changes since RFC 3272
A.1. RFC 3272
A.2. This Document
Acknowledgments
Contributors
Author's Address
This document describes the principles of Internet traffic engineering (TE). The objective of the document is to articulate the general issues and principles for Internet TE and, where appropriate, to provide recommendations, guidelines, and options for the development of preplanned (offline) and dynamic (online) Internet TE capabilities and support systems.
このドキュメントでは、インターネットトラフィックエンジニアリング（TE）の原則について説明しています。このドキュメントの目的は、インターネットTEの一般的な問題と原則を明確にすることであり、必要に応じて、事前ラン（オフライン）およびダイナミック（オンライン）インターネットTE機能とサポートシステムの開発のための推奨事項、ガイドライン、およびオプションを提供することです。
Even though Internet TE is most effective when applied end-to-end, the focus of this document is TE within a given domain (such as an Autonomous System (AS)). However, because a preponderance of Internet traffic tends to originate in one AS and terminate in another, this document also provides an overview of aspects pertaining to inter-domain TE.
インターネットTEはエンドツーエンドで適用される場合に最も効果的ですが、このドキュメントの焦点は特定のドメイン内（自律システム（AS）など）内のTEです。ただし、インターネットトラフィックの圧倒的なものは、1つのASに由来し、別のASで終了する傾向があるため、このドキュメントはドメイン間TEに関連する側面の概要も提供します。
This document provides terminology and a taxonomy for describing and understanding common Internet TE concepts.
このドキュメントは、一般的なインターネットTEの概念を説明および理解するための用語と分類法を提供します。
This work was first published as [RFC3272] in May 2002. This document obsoletes [RFC3272] by making a complete update to bring the text in line with best current practices for Internet TE and to include references to the latest relevant work in the IETF. It is worth noting around three-fifths of the RFCs referenced in this document postdate the publication of [RFC3272]. Appendix A provides a summary of changes between [RFC3272] and this document.
この作業は、2002年5月に[RFC3272]として最初に公開されました。このドキュメントは、IETFでの最新の関連作業への参照をインターネットTEの最良の現在のプラクティスに並べてテキストを並べるための完全な更新を行うことにより、[RFC3272]を廃止します。このドキュメントで参照されているRFCの約5分の3は、[RFC3272]の出版物をポストデートすることに注意する価値があります。付録Aでは、[RFC3272]とこのドキュメントの間の変更の概要を説明します。
One of the most significant functions performed in the Internet is the routing and forwarding 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 these routing and forwarding functions, to steer traffic through the network.
インターネットで実行される最も重要な機能の1つは、イングレスノードからノードへの出力へのトラフィックのルーティングと転送です。したがって、インターネットトラフィックエンジニアリングによって実行される最も特徴的な機能の1つは、ネットワークを介してトラフィックを導くためのこれらのルーティングおよび転送機能の制御と最適化です。
Internet traffic engineering is defined as that aspect of Internet network engineering dealing with the issues 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 [RFC2702] [AWD2].
インターネットトラフィックエンジニアリングは、パフォーマンス評価と運用上のIPネットワークのパフォーマンスの最適化の問題を扱うインターネットネットワークエンジニアリングのその側面として定義されています。トラフィックエンジニアリングには、インターネットトラフィックの測定、特性評価、モデリング、および制御へのテクノロジーと科学原則の適用が含まれます[RFC2702] [AWD2]。
It is the performance of the network as seen by end users of network services that is paramount. 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. This is accomplished by addressing traffic-oriented performance requirements while utilizing network resources without excessive waste and in a reliable way. Traffic-oriented performance measures include delay, delay variation, packet loss, and throughput.
最優先事項であるネットワークサービスのエンドユーザーに見られるのは、ネットワークのパフォーマンスです。エンドユーザーに見える特性は、ネットワークの緊急プロパティであり、これは全体として表示されたときのネットワークの特性です。したがって、サービスプロバイダーの中心的な目標は、経済的考慮事項を考慮しながら、ネットワークの緊急プロパティを強化することです。これは、過度の廃棄物なしで信頼できる方法でネットワークリソースを利用しながら、交通指向のパフォーマンス要件に対処することによって達成されます。トラフィック指向のパフォーマンス測定には、遅延、遅延変動、パケット損失、スループットが含まれます。
Internet TE responds to network events (such as link or node failures, reported or predicted network congestion, planned maintenance, service degradation, planned changes in the traffic matrix, etc.). Aspects of capacity management respond at intervals ranging from days to years. Routing control functions operate at intervals ranging from milliseconds to days. Packet-level processing functions operate at very fine levels of temporal resolution (up to milliseconds) while reacting to statistical measures of the real-time behavior of traffic.
Internet TEは、ネットワークイベント（リンクやノードの障害、報告または予測されたネットワークの輻輳、計画されたメンテナンス、サービスの劣化、トラフィックマトリックスの計画的変更など）に対応します。容量管理の側面は、数日から数年の範囲の間隔で対応します。ルーティング制御機能は、ミリ秒から日までの間隔で動作します。パケットレベルの処理関数は、トラフィックのリアルタイム動作の統計的測定に反応しながら、非常に細かいレベルの時間分解能（最大ミリ秒）で動作します。
Thus, the optimization aspects of TE can be viewed from a control perspective and can be both proactive and reactive. In the proactive case, the TE control system takes preventive action to protect against predicted unfavorable future network states, for example, by engineering backup paths. It may also take action that will lead to a more desirable future network state. In the reactive case, the control system responds to correct issues and adapt to network events, such as routing after failure.
したがって、TEの最適化の側面は、制御の観点から見ることができ、積極的で反応的である可能性があります。プロアクティブな場合、TE制御システムは、たとえば、バックアップパスをエンジニアリングすることにより、予測される不利な将来のネットワーク状態から保護するために予防措置を講じます。また、より望ましい将来のネットワーク状態につながるアクションを実行する場合があります。反応性の場合、制御システムは正しい問題に応答し、障害後のルーティングなどのネットワークイベントに適応します。
Another important objective of Internet TE is to facilitate reliable network operations [RFC2702]. Reliable network operations can be facilitated by providing mechanisms that enhance network integrity and by embracing policies emphasizing network survivability. This reduces the vulnerability of services to outages arising from errors, faults, and failures occurring within the network infrastructure.
インターネットTEのもう1つの重要な目的は、信頼できるネットワーク操作を促進することです[RFC2702]。信頼できるネットワーク操作は、ネットワークの整合性を高めるメカニズムを提供し、ネットワークの生存性を強調するポリシーを採用することにより、促進できます。これにより、ネットワークインフラストラクチャ内で発生するエラー、障害、障害から生じる停止に対するサービスの脆弱性が低下します。
The optimization aspects of TE can be achieved through capacity management and traffic management. 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. In this document, traffic management includes:
TEの最適化の側面は、能力管理と交通管理を通じて達成できます。このドキュメントでは、容量管理には容量計画、ルーティング制御、およびリソース管理が含まれます。特に関心のあるネットワークリソースには、リンク帯域幅、バッファスペース、計算リソースが含まれます。このドキュメントには、トラフィック管理が含まれます。
1. Nodal traffic control functions, such as traffic conditioning, queue management, and scheduling.
1. トラフィックコンディショニング、キュー管理、スケジューリングなどのノーダルトラフィック制御機能。
2. Other functions that regulate the flow of traffic through the network or that arbitrate access to network resources between different packets or between different traffic flows.
2. ネットワークを介したトラフィックの流れを調整したり、異なるパケット間または異なるトラフィックフロー間でネットワークリソースへのアクセスを仲裁する他の機能。
One major challenge of Internet TE is the realization of automated control capabilities that adapt quickly and cost-effectively to significant changes in network state, while still maintaining stability of the network. Performance evaluation can assess the effectiveness of TE methods, and the results of this evaluation can be used to identify existing problems, guide network reoptimization, and aid in the prediction of potential future problems. However, this process can also be time-consuming and may not be suitable to act on short-lived changes in the network.
インターネットTEの主要な課題の1つは、ネットワークの安定性を維持しながら、ネットワーク状態の大幅な変化に迅速かつ費用対効果に合わせて適応する自動制御機能の実現です。パフォーマンス評価は、TEメソッドの有効性を評価できます。この評価の結果を使用して、既存の問題を特定し、ネットワークの再最適化を導き、潜在的な将来の問題の予測に役立ちます。ただし、このプロセスは時間がかかる場合があり、ネットワークの短命の変更に対応するのに適していない場合があります。
Performance evaluation can be achieved in many different ways. The most notable techniques include analytic methods, simulation, and empirical methods based on measurements.
パフォーマンス評価は、さまざまな方法で達成できます。最も注目すべき手法には、測定に基づいた分析方法、シミュレーション、および経験的方法が含まれます。
Traffic engineering comes in two flavors:
交通工学には2つのフレーバーがあります。
* A background process that constantly monitors traffic and network conditions and optimizes the use of resources to improve performance.
* トラフィックとネットワークの条件を常に監視し、リソースの使用を最適化してパフォーマンスを改善するバックグラウンドプロセス。
* A form of a pre-planned traffic distribution that is considered optimal.
* 最適と見なされる事前に計画されたトラフィック分布の形式。
In the latter case, any deviation from the optimum distribution (e.g., caused by a fiber cut) is reverted upon repair without further optimization. However, this form of TE relies upon the notion that the planned state of the network is optimal. Hence, there are two levels of TE in such a mode:
後者の場合、最適化を最適化することなく、最適な分布（たとえば、ファイバーカットによって引き起こされる）からの逸脱（繊維切断によって引き起こされる）が戻ってきます。ただし、この形式のTEは、ネットワークの計画状態が最適であるという概念に依存しています。したがって、このようなモードには2つのレベルがあります。
* The TE-planning task to enable optimum traffic distribution.
* 最適なトラフィック分布を有効にするためのTEプランニングタスク。
* The routing and forwarding tasks that keep traffic flows attached to the pre-planned distribution.
* 事前に計画された分布にトラフィックフローを取り付けたままにするルーティングおよび転送タスク。
As a general rule, TE concepts and mechanisms must be sufficiently specific and well-defined to address known requirements but simultaneously flexible and extensible to accommodate unforeseen future demands (see Section 6.1).
一般的なルールとして、TEの概念とメカニズムは、既知の要件に対処するために十分に特異的かつ明確に定義されている必要がありますが、予期せぬ将来の要求に対応するために同時に柔軟で拡張可能です（セクション6.1を参照）。
As mentioned in Section 1.1, Internet traffic engineering provides performance optimization of IP networks while utilizing network resources economically and reliably. Such optimization is supported at the control/controller level and within the data/forwarding plane.
セクション1.1で述べたように、インターネットトラフィックエンジニアリングは、ネットワークリソースを経済的かつ確実に利用しながら、IPネットワークのパフォーマンスの最適化を提供します。このような最適化は、コントロール/コントローラーレベルおよびデータ/転送面内でサポートされています。
The key elements required in any TE solution are as follows:
TEソリューションに必要な重要な要素は次のとおりです。
1. Policy
1. ポリシー
2. Path steering
2. パスステアリング
3. Resource management
3. 資源管理
Some TE solutions rely on these elements to a lesser or greater extent. Debate remains about whether a solution can truly be called "TE" if it does not include all of these elements. For the sake of this document, we assert that all TE solutions must include some aspects of all of these elements. Other solutions can be classed as "partial TE" and also fall in scope of this document.
一部のソリューションは、これらの要素に依存しています。これらのすべての要素が含まれていない場合、解決策が本当に「Te」と呼ばれるかどうかについての議論は残っています。このドキュメントのために、すべてのTEソリューションにこれらすべての要素のいくつかの側面を含める必要があると主張します。他のソリューションは「部分的なte」に分類され、このドキュメントの範囲にも分類されます。
Policy allows for the selection of paths (including next hops) based on information beyond basic reachability. Early definitions of routing policy, e.g., [RFC1102] and [RFC1104], discuss routing policy being applied to restrict access to network resources at an aggregate level. BGP is an example of a commonly used mechanism for applying such policies; see [RFC4271] and [RFC8955]. In the TE context, policy decisions are made within the control plane or by controllers in the management plane and govern the selection of paths. Examples can be found in [RFC4655] and [RFC5394]. TE solutions may cover the mechanisms to distribute and/or enforce policies, but definition of specific policies is left to the network operator.
ポリシーは、基本的な到達可能性を超えた情報に基づいて、パス（次のホップを含む）の選択を許可します。ルーティングポリシーの初期の定義、例えば[RFC1102]および[RFC1104]は、集計レベルでネットワークリソースへのアクセスを制限するために適用されるルーティングポリシーについて議論します。BGPは、そのようなポリシーを適用するために一般的に使用されるメカニズムの例です。[RFC4271]および[RFC8955]を参照してください。TEのコンテキストでは、政策決定は制御プレーン内または管理プレーン内のコントローラーによって行われ、パスの選択を管理します。例は[RFC4655]および[RFC5394]に記載されています。TEソリューションは、ポリシーを配布および/または実施するメカニズムをカバーする場合がありますが、特定のポリシーの定義はネットワークオペレーターに任されています。
Path steering is the ability to forward packets using more information than just knowledge of the next hop. Examples of path steering include IPv4 source routes [RFC0791], RSVP-TE explicit routes [RFC3209], Segment Routing (SR) [RFC8402], and Service Function Chaining [RFC7665]. Path steering for TE can be supported via control plane protocols, by encoding in the data plane headers, or by a combination of the two. This includes when control is provided by a controller using a network-facing control protocol.
パスステアリングとは、次のホップの知識よりも多くの情報を使用してパケットを転送する機能です。パスステアリングの例には、IPv4ソースルート[RFC0791]、RSVP-TE明示的ルート[RFC3209]、セグメントルーティング（SR）[RFC8402]、およびサービス関数[RFC7665]が含まれます。TEのパスステアリングは、コントロールプレーンプロトコルを介して、データプレーンヘッダーでエンコードすること、または2つの組み合わせによってサポートできます。これには、ネットワーク向けのコントロールプロトコルを使用してコントローラーによって制御が提供される場合が含まれます。
Resource management provides resource-aware control and forwarding. Examples of resources are bandwidth, buffers, and queues, all of which can be managed to control loss and latency.
リソース管理は、リソース認識の制御と転送を提供します。リソースの例は、帯域幅、バッファー、キューであり、これらはすべて損失と遅延を制御するために管理できます。
Resource reservation is the control aspect of resource management. It provides for domain-wide consensus about which network resources are used by a particular flow. This determination may be made at a very coarse or very fine level. Note that this consensus exists at the network control or controller level but not within the data plane. It may be composed purely of accounting/bookkeeping, but it typically includes an ability to admit, reject, or reclassify a flow based on policy. Such accounting can be done based on any combination of a static understanding of resource requirements and the use of dynamic mechanisms to collect requirements (e.g., via RSVP-TE [RFC3209]) and resource availability (e.g., via OSPF extensions for GMPLS [RFC4203]).
リソースの予約は、リソース管理の制御側の側面です。特定のフローで使用されるネットワークリソースについてのドメイン全体のコンセンサスを提供します。この決定は、非常に粗いまたは非常に細かいレベルで行われる場合があります。このコンセンサスは、ネットワークコントロールまたはコントローラーレベルに存在するが、データプレーン内では存在しないことに注意してください。それは純粋に会計/簿記で構成されているかもしれませんが、通常、ポリシーに基づいてフローを認め、拒否、または再分類する能力が含まれます。このような会計は、リソース要件の静的な理解と要件を収集するための動的メカニズムの使用（例：RSVP-TE [RFC3209]を介して）およびリソースの可用性（例：GMPLのOSPF拡張）を介して行うことに基づいて行うことができます[RFC4203]）。
Resource allocation is the data plane aspect of resource management. It provides for the allocation of specific node and link resources to specific flows. Example resources include buffers, policing, and rate-shaping mechanisms that are typically supported via queuing. Resource allocation also includes the matching of a flow (i.e., flow classification) to a particular set of allocated resources. The method of flow classification and granularity of resource management is technology-specific. Examples include Diffserv with dropping and remarking [RFC4594], MPLS-TE [RFC3209], GMPLS-based Label Switched Paths (LSPs) [RFC3945], as well as controller-based solutions [RFC8453]. This level of resource control, while optional, is important in networks that wish to support network congestion management policies to control or regulate the offered traffic to deliver different levels of service and alleviate network congestion problems. It is also important in networks that wish to control the latency experienced by specific traffic flows.
リソース割り当ては、リソース管理のデータプレーンの側面です。特定のノードとリンクリソースの割り当てを特定のフローに提供します。リソースの例には、通常、キューイングを介してサポートされるバッファー、ポリシング、およびレート形成メカニズムが含まれます。リソースの割り当てには、フロー（つまり、フロー分類）の特定の割り当てられたリソースセットへのマッチングも含まれます。リソース管理のフロー分類と粒度の方法は、技術固有です。例には、[RFC4594]、MPLS-TE [RFC3209]、GMPLSベースのラベルスイッチ付きパス（LSP）[RFC3945]、およびコントローラーベースのソリューション[RFC8453]、ドロップおよびリムアークのDiffServが含まれます。このレベルのリソース制御は、オプションではありますが、ネットワーク渋滞管理ポリシーをサポートし、提供されたトラフィックを制御または規制して、さまざまなレベルのサービスを提供し、ネットワークの混雑の問題を軽減するネットワークで重要です。また、特定のトラフィックフローが経験するレイテンシーを制御したいネットワークでも重要です。
The scope of this document is intra-domain TE because this is the practical level of TE technology that exists in the Internet at the time of writing. That is, this document describes TE within a given AS in the Internet. This document discusses concepts pertaining to intra-domain traffic control, including such issues as routing control, micro and macro resource allocation, and control coordination problems that arise consequently.
このドキュメントの範囲は、ドメイン内のTEです。これは、執筆時点でインターネットに存在するTEテクノロジーの実用的なレベルであるためです。つまり、このドキュメントは、インターネットのように与えられた範囲内のTEについて説明しています。このドキュメントでは、ルーティング制御、マイクロおよびマクロリソースの割り当て、結果として生じる制御調整の問題など、ドメイン内のトラフィックコントロールに関する概念について説明します。
This document describes and characterizes techniques already in use or in advanced development for Internet TE. The way these techniques fit together is discussed and scenarios in which they are useful are identified.
このドキュメントでは、インターネットTEの使用または高度な開発において、すでに使用されている技術を説明および特徴付けます。これらの手法が一緒に適合する方法について説明し、それらが有用なシナリオが特定されます。
Although the emphasis in this document is on intra-domain traffic engineering, an overview of the high-level considerations pertaining to inter-domain TE is provided in Section 7. Inter-domain Internet TE is crucial to the performance enhancement of the world-wide Internet infrastructure.
このドキュメントの重点はドメイン内トラフィックエンジニアリングにありますが、ドメイン間TEに関連する高レベルの考慮事項の概要をセクション7で提供します。インターネットインフラストラクチャ。
Whenever possible, relevant requirements from existing IETF documents and other sources are incorporated by reference.
可能な場合はいつでも、既存のIETFドキュメントおよびその他のソースからの関連要件が参照により組み込まれています。
This section provides terminology that is useful for Internet TE. The definitions presented apply to this document. These terms may have other meanings elsewhere.
このセクションでは、インターネットTEに役立つ用語を提供します。提示された定義は、このドキュメントに適用されます。これらの用語は他の場所に他の意味を持っているかもしれません。
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時間の期間。
Congestion:
混雑：
A state of a network resource in which the traffic incident on the resource exceeds its output capacity over an interval of time. A small amount of congestion may be beneficial to ensure that network resources are run at full capacity, and this may be particularly true at the network edge where it is desirable to ensure that user traffic is served as much as possible. Within the network, if congestion is allowed to build (such as when input traffic exceeds output traffic in a sustained way), it will have a negative effect on user traffic.
リソース上のトラフィックインシデントが時間間隔で出力容量を超えるネットワークリソースの状態。ネットワークリソースがフル容量で実行されることを保証するためには、少量の混雑が有益である可能性があります。これは、ユーザートラフィックが可能な限り提供されることが望ましいネットワークエッジで特に当てはまる場合があります。ネットワーク内では、輻輳が構築されている場合（入力トラフィックが持続的な方法で出力トラフィックを超えるなど）、ユーザートラフィックに悪影響を及ぼします。
Congestion avoidance:
混雑回避：
An approach to congestion management that attempts to obviate the occurrence of congestion. It is chiefly relevant to network congestion, although it may form a part of demand-side congestion management.
混雑の発生を取り除こうとする混雑管理へのアプローチ。それは主にネットワークの輻輳に関連していますが、需要側の輻輳管理の一部を形成する可能性があります。
Congestion response:
混雑反応：
An approach to congestion management that attempts to remedy congestion problems that have already occurred.
すでに発生した混雑の問題を改善しようとする混雑管理へのアプローチ。
Constraint-based routing:
制約ベースのルーティング：
A class of routing protocols that takes 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-based routing.
ルーティングの決定を行う際に、指定されたトラフィック属性、ネットワークの制約、およびポリシーの制約を考慮するルーティングプロトコルのクラス。制約ベースのルーティングは、トラフィックの集合体とフローに適用できます。QoSベースのルーティングの一般化です。
Demand-side congestion management:
需要側の混雑管理：
A congestion management scheme that addresses congestion problems by regulating or conditioning the 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. See [KELLY] for a more mathematical definition.
フローまたはトラフィックの集合体に「許容可能なサービス品質」を提供するために、フローまたはトラフィックの集合体に割り当てることができる帯域幅の最小量。より数学的な定義については、[Kelly]を参照してください。
Egress node:
出力ノード：
The device (router) at which traffic leaves a network toward a destination (host, server, etc.) or to another network.
トラフィックを宛先（ホスト、サーバーなど）または別のネットワークに向けてネットワークを離れるデバイス（ルーター）。
End-to-end:
端から端まで：
This term is context-dependent and often applies to the life of a traffic flow from original source to final destination. In contrast, edge-to-edge is often used to describe the traffic flow from the entry of a domain or network to the exit of that domain or network. However, in some contexts (for example, where there is a service interface between a network and the client of that network or where a path traverses multiple domains under the control of a single process), end-to-end is used to refer to the full operation of the service that may be composed of concatenated edge-to-edge operations. Thus, in the context of TE, the term "end-to-end" may refer to the full TE path but not to the complete path of the traffic from source application to ultimate destination.
この用語はコンテキスト依存であり、多くの場合、元のソースから最終目的地への交通流の寿命に適用されます。対照的に、エッジからエッジは、ドメインまたはネットワークのエントリからそのドメインまたはネットワークの出口へのトラフィックフローを記述するためによく使用されます。ただし、一部のコンテキストでは（たとえば、ネットワークとそのネットワークのクライアントの間にサービスインターフェイスがある場合、またはパスが単一のプロセスの制御下で複数のドメインを通過する場合）、エンドツーエンドを使用して参照するために使用されます。連結されたエッジからエッジへの操作で構成される可能性のあるサービスの完全な動作。したがって、TEのコンテキストでは、「エンドツーエンド」という用語は、完全なTEパスを指しますが、ソースアプリケーションから最終目的地までのトラフィックの完全なパスを指す場合があります。
Hotspot:
ホットスポット：
A network element or subsystem that is in a considerably higher state of congestion than others.
他のものよりもかなり高い輻輳状態にあるネットワーク要素またはサブシステム。
Ingress node:
Ingressノード：
The device (router) at which traffic enters a network from a source (host) or from another network.
トラフィックがソース（ホスト）または別のネットワークからネットワークに入るデバイス（ルーター）。
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 congestion:
ネットワークの混雑：
Congestion within the network at a specific node or a specific link that is sufficiently extreme that it results in unacceptable queuing delay or packet loss. Network congestion can negatively impact end-to-end or edge-to-edge traffic flows, so TE schemes may be deployed to balance traffic in the network and deliver congestion avoidance.
特定のノードまたは特定のリンクでのネットワーク内の混雑は、容認できないキューイングの遅延またはパケット損失をもたらすほど十分に極端です。ネットワークの輻輳は、エンドツーエンドまたはエッジツーエッジのトラフィックフローに悪影響を与える可能性があるため、ネットワークのトラフィックのバランスをとり、混雑回避を実現するために、TEスキームを展開することができます。
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を提供する機能。
Offered load:
提供された負荷：
Offered load is also sometimes called "offered traffic load". It is a measure of the amount of traffic being presented to be carried across a network compared to the capacity of the network to carry it. This term derives from queuing theory, and an offered load of 1 indicates that the network can carry, but only just manage to carry, all of the traffic presented to it.
提供された負荷は、「提供されたトラフィック負荷」とも呼ばれることもあります。これは、ネットワークを携帯する容量と比較して、ネットワークを介して運ばれるトラフィックの量の尺度です。この用語はキューイング理論に由来し、提供された1の負荷は、ネットワークが携帯することができるが、それだけのすべてのトラフィックを運ぶことができることを示しています。
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 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.
特定のリクエストを満たすためにネットワークリソースを割り当てまたは構成するプロセス。
Quality of Service (QoS):
サービス品質（QoS）：
QoS [RFC3198] refers to the mechanisms used within a network to achieve specific goals for the delivery of traffic for a particular service according to the parameters specified in a Service Level Agreement. "Quality" is characterized by service availability, delay, jitter, throughput, and packet loss ratio. At a network resource level, "Quality of Service" refers to a set of capabilities that allow a service provider to prioritize traffic, control bandwidth, and network latency.
QOS [RFC3198]は、サービスレベル契約で指定されたパラメーターに従って、特定のサービスのトラフィックの配信のための特定の目標を達成するためにネットワーク内で使用されるメカニズムを指します。「品質」は、サービスの可用性、遅延、ジッター、スループット、およびパケット損失率によって特徴付けられます。ネットワークリソースレベルでは、「サービス品質」とは、サービスプロバイダーがトラフィック、制御帯域幅、およびネットワークレイテンシを優先できるようにする一連の機能を指します。
QoS routing:
QoSルーティング：
Class of routing systems that selects paths to be used by a flow based on the QoS requirements of the flow.
フローのQoS要件に基づいてフローによって使用されるパスを選択するルーティングシステムのクラス。
Service Level Agreement (SLA):
サービスレベル契約（SLA）：
A contract between a provider and a customer that guarantees specific levels of performance and reliability at a certain cost.
特定のコストで特定のレベルのパフォーマンスと信頼性を保証するプロバイダーと顧客との間の契約。
Service Level Objective (SLO):
サービスレベルの目的（SLO）：
A key element of an SLA between a provider and a customer. SLOs are agreed upon as a means of measuring the performance of the service provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding.
プロバイダーと顧客の間のSLAの重要な要素。SLOは、サービスプロバイダーのパフォーマンスを測定する手段として合意されており、誤解に基づいて両当事者間の紛争を回避する方法として概説されています。
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.
既存および/または予想される混雑問題に対処するための追加のネットワークリソースを提供する渋滞管理スキーム。
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 together to accomplish traffic-engineering objectives.
トラフィックエンジニアリング目標を達成するために一緒に使用されるオブジェクト、メカニズム、およびプロトコルのコレクション。
Traffic flow:
交通流：
A stream of packets between two endpoints that can be characterized in a certain way. A common classification for a traffic flow selects packets with the five-tuple of source and destination addresses, source and destination ports, and protocol ID. Flows may be very small and transient, ranging to very large. The TE techniques described in this document are likely to be more effective when applied to large flows. Traffic flows may be aggregated and treated as a single unit in some forms of TE, making it possible to apply TE to the smaller flows that comprise the aggregate.
特定の方法で特徴付けられる2つのエンドポイント間のパケットのストリーム。トラフィックフローの一般的な分類は、ソースおよび宛先アドレス、ソースポートと宛先ポート、およびプロトコルIDの5タプルを使用してパケットを選択します。フローは非常に小さく、一時的なものであり、非常に大きくなります。このドキュメントで説明されているテクニックは、大きなフローに適用するとより効果的である可能性があります。トラフィックフローは集約され、ある形式のTEの単一ユニットとして扱われる場合があり、骨材を構成する小さなフローにTEを適用することが可能になります。
Traffic mapping:
トラフィックマッピング：
Traffic mapping is the assignment of traffic workload onto (pre-established) paths to meet certain requirements.
トラフィックマッピングは、特定の要件を満たすために（事前に確立された）パスへのトラフィックワークロードの割り当てです。
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 that are forwarded through a common path. A traffic trunk may be characterized by an ingress and egress node and a set of attributes that determine its behavioral characteristics and requirements from the network.
共通の経路を介して転送される同じクラスに属する交通流の集約。トラフィックトランクは、ネットワークからの行動特性と要件を決定する侵入と出口ノード、および一連の属性によって特徴付けられる場合があります。
Workload:
ワークロード：
Workload is also sometimes called "traffic workload". It is an evaluation of the amount of work that must be done in a network in order to facilitate the traffic demand. Colloquially, it is the answer to, "How busy is the network?"
ワークロードは、「トラフィックワークロード」とも呼ばれることもあります。これは、交通需要を促進するためにネットワークで行う必要がある作業量の評価です。口語的には、「ネットワークはどれくらい忙しいですか？」
The Internet aims to convey IP packets from ingress nodes to egress nodes efficiently, expeditiously, and economically. Furthermore, in a multi-class service environment (e.g., Diffserv capable networks; see Section 5.1.1.2), 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 the network. Thus, consideration must be given to resolving competition for network resources between traffic flows belonging to the same service class (intra-class contention resolution) and traffic flows belonging to different classes (inter-class contention resolution).
インターネットは、IPパケットをイングレスノードからノードに効率的に、迅速に、経済的に脱出させることを目指しています。さらに、マルチクラスのサービス環境（例：DiffServ対応ネットワーク、セクション5.1.1.2を参照）では、ネットワークのリソース共有パラメーターを適切に決定および構成する必要があります。ネットワークを通過するパケット間の相互干渉から。したがって、同じサービスクラス（クラス内の競合解像度）に属するトラフィックフローと、異なるクラスに属するトラフィックフロー（クラス間競合解決）の間のネットワークリソースの競争を解決することを考慮しなければなりません。
The context of Internet traffic engineering includes the following sub-contexts:
インターネットトラフィックエンジニアリングのコンテキストには、次のサブコンテキストが含まれています。
1. A network domain context that defines the scope under consideration and, in particular, the situations in which the TE problems occur. The network domain context includes network structure, policies, characteristics, constraints, quality attributes, and optimization criteria.
1. 検討中の範囲、特にTEの問題が発生する状況を定義するネットワークドメインコンテキスト。ネットワークドメインのコンテキストには、ネットワーク構造、ポリシー、特性、制約、品質属性、および最適化基準が含まれます。
2. A problem context defining the general and concrete issues that TE 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. TEが対処する一般的および具体的な問題を定義する問題コンテキスト。問題のコンテキストには、識別、関連する機能の抽象化、表現、定式化、ソリューションスペースの要件の仕様、および許容可能なソリューションの望ましい機能の仕様が含まれます。
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 instantiated. The implementation and operational context includes planning, organization, and execution.
4. ソリューションがインスタンス化される実装と運用コンテキスト。実装と運用コンテキストには、計画、組織、および実行が含まれます。
The context of Internet TE and the different problem scenarios are discussed in the following subsections.
インターネットTEのコンテキストとさまざまな問題シナリオについては、以下のサブセクションで説明します。
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ネットワークのサイズは、特定の場所内にあるルーターの小さなクラスターから、世界中に分散されている数千の相互接続されたルーター、スイッチ、およびその他のコンポーネントにまで及びます。
At the most basic level of abstraction, an IP network can be represented as a distributed dynamic system consisting of:
抽象化の最も基本的なレベルでは、IPネットワークは以下で構成される分散動的システムとして表現できます。
* a set of interconnected resources that provide transport services for IP traffic subject to certain constraints
* 特定の制約の対象となるIPトラフィックに輸送サービスを提供する相互接続されたリソースのセット
* a demand system representing the offered load to be transported through the network
* ネットワークを介して輸送される提供された負荷を表す需要システム
* a response system consisting of network processes, protocols, and related mechanisms that facilitate the movement of traffic through the network (see also [AWD2])
* ネットワークプロセス、プロトコル、およびネットワークを介したトラフィックの移動を促進する関連メカニズムで構成される応答システム（[AWD2]も参照）
The network elements and resources may have specific characteristics restricting the manner in which the traffic demand is handled. Additionally, network resources may be equipped with traffic control mechanisms managing the way in which the demand is serviced. Traffic control mechanisms may be used to:
ネットワーク要素とリソースには、交通需要の処理方法を制限する特定の特性があります。さらに、ネットワークリソースには、需要が整備される方法を管理するトラフィックコントロールメカニズムを備えている場合があります。トラフィックコントロールメカニズムは次のように使用できます。
* control packet processing activities within a given resource
* 特定のリソース内のパケット処理アクティビティを制御します
* arbitrate contention for access to the resource by different packets
* 異なるパケットによるリソースへのアクセスのためのarbitrate競合
* 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 carries 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 service provided by the network also depend 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.
ネットワークの携帯方法の詳細は、ネットワーク管理者のポリシーでパケットを指定し、ネットワーク構成管理およびポリシーベースのプロビジョニングシステムを通じてインストールされます。一般に、ネットワークが提供するサービスの種類は、ネットワーク要素とプロトコルのテクノロジーと特性、一般的なサービスとユーティリティモデル、およびネットワーク管理者がポリシーをネットワーク構成に変換する機能にも依存します。
Internet networks have two significant characteristics:
インターネットネットワークには2つの重要な特性があります。
* They provide real-time services.
* リアルタイムサービスを提供します。
* Their operating environments are very dynamic.
* それらの動作環境は非常に動的です。
The dynamic characteristics of IP and IP/MPLS networks can be attributed in part to fluctuations in demand, the interaction between various network protocols and processes, the rapid evolution of the infrastructure that demands the constant inclusion of new technologies and new network elements, and the transient and persistent faults that occur within the system.
IPおよびIP/MPLSネットワークの動的特性は、需要の変動、さまざまなネットワークプロトコルとプロセスの相互作用、新しいテクノロジーと新しいネットワーク要素の絶え間ない含有を要求するインフラストラクチャの急速な進化、およびシステム内で発生する一時的で持続的な障害。
Packets contend for the use of network resources as they are conveyed through the network. A network resource is considered to be congested if, for an interval of time, the arrival rate of packets exceeds the output capacity of the resource. Network congestion may result in some of the arriving packets being delayed or even dropped.
ネットワークリソースは、ネットワークを介して伝達されるため、ネットワークリソースを使用するために競合します。パケットの到着率がリソースの出力容量を超える場合、ネットワークリソースは混雑していると見なされます。ネットワークの輻輳により、到着するパケットの一部が遅延または削除される可能性があります。
Network congestion increases transit delay and delay variation, may lead to packet loss, and reduces the predictability of network services. Clearly, while congestion may be a useful tool at ingress edge nodes, network congestion is highly undesirable. Combating network congestion at a reasonable cost is a major objective of Internet TE, although it may need to be traded with other objectives to keep the costs reasonable.
ネットワークの輻輳は、輸送遅延と遅延の変動を増加させ、パケットの損失につながり、ネットワークサービスの予測可能性を低下させる可能性があります。明らかに、輻輳はイングレスエッジノードの有用なツールかもしれませんが、ネットワークの混雑は非常に望ましくありません。ネットワークの混雑と合理的なコストで闘うことは、インターネットTEの主要な目的ですが、コストを合理的に保つために他の目標と取引する必要がある場合があります。
Efficient sharing of network resources by multiple traffic flows is a basic operational premise for the Internet. A fundamental challenge in network operation is to increase resource utilization while minimizing the possibility of congestion.
複数のトラフィックフローによるネットワークリソースの効率的な共有は、インターネットの基本的な運用前提です。ネットワーク運用における基本的な課題は、混雑の可能性を最小限に抑えながら、リソースの利用を増やすことです。
The Internet has to function in the presence of different classes of traffic with different service requirements. This requirement is clarified in the architecture for Differentiated Services (Diffserv) [RFC2475]. That document describes how packets can be grouped into behavior aggregates such that each aggregate has a common set of behavioral characteristics or a common set of delivery requirements. Delivery requirements of a specific set of packets may be specified explicitly or implicitly. Two of the most important traffic delivery requirements are:
インターネットは、さまざまなサービス要件を持つさまざまなクラスのトラフィックの存在下で機能する必要があります。この要件は、差別化されたサービスのアーキテクチャ（diffserv）[RFC2475]で明確にされています。そのドキュメントでは、各集合体が動作特性の共通セットまたは共通の配信要件を持つように、パケットを動作集合体にグループ化する方法について説明します。特定のパケットセットの配信要件は、明示的または暗黙的に指定できます。最も重要なトラフィック配送要件の2つは次のとおりです。
* 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:
* QoS要件は、次の点で表現できます。
- integrity constraints, such as packet loss
- パケット損失などの整合性の制約
- 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)
- 各パケットの配信のタイミング制限（遅延）や同じトラフィックストリームに属する連続したパケットの配信のタイミング制限などの時間的制約（遅延変動）
There are several problems associated with operating a network like those described in the previous section. This section analyzes the problem context in relation to TE. The identification, abstraction, representation, and measurement of network features relevant to TE are significant issues.
前のセクションで説明したようなネットワークの操作に関連するいくつかの問題があります。このセクションでは、TEに関連する問題のコンテキストを分析します。TEに関連するネットワーク機能の識別、抽象化、表現、および測定は重大な問題です。
A particular challenge is to formulate the problems that traffic engineering attempts to solve. For example:
特定の課題は、交通工学が解決しようとする問題を策定することです。例えば：
* How to identify the requirements on the solution space
* ソリューションスペースの要件を識別する方法
* How to specify the desirable features of solutions
* ソリューションの望ましい機能を指定する方法
* How to actually solve the problems
* 実際に問題を解決する方法
* How to measure and characterize the effectiveness of solutions
* ソリューションの有効性を測定および特徴付ける方法
Another class of problems is how to measure and estimate relevant network state parameters. Effective TE relies on a good estimate of the offered traffic load as well as a view of the underlying topology and associated resource constraints. Offline planning requires a full view of the topology of the network or partial network that is being planned.
別のクラスの問題は、関連するネットワーク状態パラメーターを測定および推定する方法です。効果的なTEは、提供されるトラフィック負荷の適切な推定値と、基礎となるトポロジと関連するリソースの制約の見解に依存しています。オフラインの計画には、計画されているネットワークまたは部分的なネットワークのトポロジーの完全なビューが必要です。
Still another class of problem is how to characterize the state of the network and how to evaluate its performance. The performance evaluation problem is two-fold: one aspect relates to the evaluation of the system-level performance of the network, and the other aspect relates to the evaluation of resource-level performance, which restricts attention to the performance analysis of individual network resources.
さらに別のクラスの問題は、ネットワークの状態をどのように特徴付ける方法と、そのパフォーマンスを評価する方法です。パフォーマンス評価の問題は2つあります。1つの側面は、ネットワークのシステムレベルのパフォーマンスの評価に関連しており、もう1つの側面は、個々のネットワークリソースのパフォーマンス分析への注意を制限するリソースレベルのパフォーマンスの評価に関連しています。
In this document, 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. Correspondingly, we refer to the TE schemes dealing with network performance optimization at the systems level as "macro-TE" and the schemes that optimize at the individual resource level as "micro-TE." Under certain circumstances, the system-level performance can be derived from the resource-level performance using appropriate rules of composition, depending upon the particular performance measures of interest.
このドキュメントでは、ネットワークのシステムレベルの特性を「マクロステート」と呼び、リソースレベルの特性を「マイクロステート」と呼びます。システムレベルの特性は、ネットワークの緊急プロパティとしても知られています。それに対応して、システムレベルでのネットワークパフォーマンスの最適化を扱うTEスキームを「マクロテ」と呼び、個々のリソースレベルで最適化するスキームを「マイクロテ」と呼びます。特定の状況では、特定の関心のあるパフォーマンス測定に応じて、システムレベルのパフォーマンスを、適切な構成ルールを使用してリソースレベルのパフォーマンスから導き出すことができます。
Another fundamental class of problem concerns how to effectively optimize network performance. Performance optimization may entail translating solutions for specific TE problems into network configurations. Optimization may also entail some degree of resource management control, routing control, and capacity augmentation.
別の基本的なクラスの問題は、ネットワークパフォーマンスを効果的に最適化する方法に関するものです。パフォーマンスの最適化には、特定のTE問題のソリューションをネットワーク構成に翻訳する必要があります。最適化には、ある程度のリソース管理制御、ルーティング制御、容量の増強が必要になる場合があります。
Network 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. Although congestion at the edge of the network may be beneficial in ensuring that the network delivers as much traffic as possible, network congestion almost always results in degradation of service quality to end users. Congestion avoidance and response schemes can include demand-side policies and supply-side policies. Demand-side policies may restrict access to congested resources 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 reallocate network resources by redistributing traffic over the infrastructure. Traffic redistribution and resource reallocation serve to increase the effective capacity of the network.
ネットワークの混雑は、運用上のIPコンテキストで最も重要な問題の1つです。ネットワーク要素は、時間間隔で持続的な過負荷を経験した場合、混雑していると言われています。ネットワークの端での混雑は、ネットワークができるだけ多くのトラフィックを提供することを保証するのに有益であるかもしれませんが、ネットワークの混雑はほとんどの場合、エンドユーザーにサービス品質を低下させます。混雑回避および対応スキームには、需要側のポリシーと供給側のポリシーが含まれます。需要側のポリシーは、混雑したリソースへのアクセスを制限するか、過負荷の状況を軽減するために需要を動的に規制する場合があります。供給側のポリシーは、提供されたトラフィックに適切に対応するために、ネットワーク容量を拡大または増強する場合があります。供給側のポリシーは、インフラストラクチャ上のトラフィックを再配布することにより、ネットワークリソースを再配分することもできます。トラフィックの再配布とリソースリアルロケーションは、ネットワークの効果的な容量を高めるのに役立ちます。
The emphasis of this document 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 document 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 TE involves analysis, evaluation of alternatives, and choice between alternative courses of action. Generally, the solution context is based on making inferences about the current or future state of the network and making 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, derivation of solutions that may be implicitly or explicitly formulated, and possibly instantiation of 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.
インターネットTEのソリューションコンテキストには、分析、代替の評価、および代替アクションコースの選択が含まれます。一般に、ソリューションのコンテキストは、ネットワークの現在または将来の状態について推論を行い、代替のアクションセット間の好みを伴う可能性のある決定を下すことに基づいています。より具体的には、ソリューションコンテキストでは、トラフィックワークロードの合理的な推定、ネットワーク状態の特性評価、暗黙的または明示的に定式化される可能性のあるソリューションの導出、およびおそらく一連の制御アクションのインスタンス化が必要です。制御アクションには、ルーティングに関連するパラメーターの操作、戦術能力の獲得の制御、およびトラフィック管理機能の制御が含まれる場合があります。
The following list of instruments may be applicable to the solution context of Internet TE:
次の機器リストは、インターネットTEのソリューションコンテキストに適用できます。
* A set of policies, objectives, and requirements (which may be context dependent) for network performance evaluation and performance optimization.
* ネットワークパフォーマンスの評価とパフォーマンスの最適化のための、一連のポリシー、目的、および要件（コンテキストに依存する可能性があります）。
* A collection of online and, in some cases, possibly offline tools and mechanisms for measurement, characterization, modeling, control of traffic, control over the placement and allocation of network resources, as well as control over the mapping or distribution of traffic onto the infrastructure.
* オンライン、場合によっては、測定、特性評価、モデリング、トラフィックの制御、ネットワークリソースの配置の制御、およびインフラストラクチャへのマッピングまたはトラフィックの配布の制御のためのオフラインツールとメカニズムのコレクション。
* A set of constraints on the operating environment, the network protocols, and the TE system itself.
* 動作環境、ネットワークプロトコル、およびTEシステム自体の一連の制約。
* A set of quantitative and qualitative techniques and methodologies for abstracting, formulating, and solving TE problems.
* TEの問題を抽象化、策定、および解決するための一連の定量的および定性的手法と方法論。
* A set of administrative control parameters that may be manipulated through a configuration management system. Such a system may itself include a configuration control subsystem, a configuration repository, a configuration accounting subsystem, and a configuration auditing subsystem.
* 構成管理システムを介して操作できる一連の管理制御パラメーター。このようなシステム自体には、構成制御サブシステム、構成リポジトリ、構成アカウンティングサブシステム、および構成監査サブシステムが含まれる場合があります。
* A set of guidelines for network performance evaluation, performance optimization, and performance improvement.
* ネットワークのパフォーマンス評価、パフォーマンスの最適化、パフォーマンスの改善に関する一連のガイドライン。
Determining traffic characteristics through measurement or estimation is very useful within the realm of the TE solution space. Traffic estimates can be derived from customer subscription information, traffic projections, traffic models, and actual measurements. The measurements may be performed at different levels, e.g., at the traffic-aggregate level or at the flow level. Measurements at the flow level or on small traffic aggregates may be performed at edge nodes, when traffic enters and leaves the network. Measurements for large traffic aggregates may be performed within the core of the network.
測定または推定による交通特性を決定することは、TEソリューション空間の領域内で非常に有用です。トラフィックの見積もりは、顧客のサブスクリプション情報、トラフィック予測、トラフィックモデル、および実際の測定から導き出すことができます。測定は、たとえば、交通総合レベルまたはフローレベルで、さまざまなレベルで実行できます。トラフィックがネットワークに入って出発するときに、フローレベルまたは小さなトラフィック集合体での測定は、エッジノードで実行される場合があります。ネットワークのコア内で、大きなトラフィック集合体の測定が実行される場合があります。
To conduct performance studies and to support planning of existing and future networks, a routing analysis may be performed to determine the paths the routing protocols will choose for various traffic demands and to ascertain the utilization of network resources as traffic is routed through the network. Routing analysis captures 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 exist) and over the underlying network infrastructure. A model of network topology is necessary to perform routing analysis. A network topology model may be extracted from:
パフォーマンス研究を実施し、既存および将来のネットワークの計画をサポートするために、ルーティング分析を実行して、ルーティングプロトコルがさまざまなトラフィック要求に対して選択するパスを決定し、ネットワークを介してトラフィックがルーティングされるときにネットワークリソースの利用を確認することができます。ルーティング分析は、ネットワークを介したパスの選択、複数の実行可能なルートにわたるトラフィックの割り当て、およびトラフィックトランク（そのようなコンストラクトが存在する場合）および基礎となるネットワークインフラストラクチャ上のIPトラフィックの多重化をキャプチャします。ルーティング分析を実行するには、ネットワークトポロジのモデルが必要です。ネットワークトポロジモデルは、以下から抽出される場合があります。
* network architecture documents
* ネットワークアーキテクチャドキュメント
* network designs
* ネットワークデザイン
* information contained in router configuration files
* ルーター構成ファイルに含まれる情報
* routing databases such as the link-state database of an Interior Gateway Protocol (IGP)
* インテリアゲートウェイプロトコル（IGP）のリンク状態データベースなどのルーティングデータベース
* routing tables
* ルーティングテーブル
* automated tools that discover and collate network topology information
* ネットワークトポロジ情報を発見および照合する自動化されたツール
Topology information may also be derived from servers that monitor network state and from servers that perform provisioning functions.
トポロジー情報は、ネットワーク状態を監視するサーバーやプロビジョニング機能を実行するサーバーから導出される場合があります。
Routing in operational IP networks can be administratively controlled at various levels of abstraction, including the manipulation of BGP attributes and IGP metrics. For path-oriented technologies such as MPLS, routing can be further controlled by the manipulation of relevant TE parameters, resource parameters, and administrative policy constraints. Within the context of MPLS, the path of an explicitly routed LSP can be computed and established in various ways, including:
運用上のIPネットワークのルーティングは、BGP属性やIGPメトリックの操作など、さまざまなレベルの抽象化で管理上制御できます。MPLSなどのパス指向のテクノロジーの場合、関連するTEパラメーター、リソースパラメーター、および管理ポリシーの制約の操作により、ルーティングをさらに制御できます。MPLSのコンテキスト内で、明示的にルーティングされたLSPの経路は、以下を含むさまざまな方法で計算および確立できます。
* manually
* 手動で
* automatically and online using constraint-based routing processes implemented on Label Switching Routers (LSRs)
* ラベルスイッチングルーター（LSR）に実装された制約ベースのルーティングプロセスを使用して自動的かつオンライン
* automatically and offline using constraint-based routing entities implemented on external TE support systems
* 外部TEサポートシステムに実装された制約ベースのルーティングエンティティを使用して自動的かつオフライン
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.
混雑を最小限に抑えることは、インターネットトラフィックエンジニアリングの重要な側面です。このサブセクションは、混雑と戦うために使用または提案されている一般的なアプローチの概要を示しています。
Congestion management policies can be categorized based upon the following criteria (see [YARE95] for a more detailed taxonomy of congestion control schemes):
混雑管理ポリシーは、次の基準に基づいて分類できます（輻輳制御スキームのより詳細な分類法については、[Yare95]を参照）。
1. Congestion Management Based on Response Timescales
1. 応答タイムスケールに基づく輻輳管理
* Long (weeks to months): Expanding network capacity by adding new equipment, routers, and links takes time and is comparatively costly. Capacity planning needs to take this into consideration. Network capacity is expanded based on estimates or forecasts of future traffic development and traffic distribution. These upgrades are typically carried out over weeks, months, or maybe even years.
* 長い（数週間から数か月）：新しい機器、ルーター、リンクを追加することでネットワーク容量を拡大するには時間がかかり、比較的コストがかかります。能力計画はこれを考慮する必要があります。ネットワーク容量は、将来のトラフィック開発と交通量の分布の推定または予測に基づいて拡張されます。これらのアップグレードは通常、数週間、数か月、あるいは数年にわたって実行されます。
* Medium (minutes to days): Several control policies fall within the medium timescale category. Examples include:
* 中（数分〜日）：いくつかの制御ポリシーは、中程度のタイムスケールカテゴリに分類されます。例は次のとおりです。
a. Adjusting routing protocol parameters to route traffic away from or towards certain segments of the network.
a. ルーティングプロトコルパラメーターを調整して、トラフィックをネットワークの特定のセグメントから離してルーティングします。
b. Setting up or adjusting explicitly routed LSPs in MPLS networks to route traffic trunks away from possibly congested resources or toward possibly more favorable routes.
b. MPLSネットワークで明示的にルーティングされたLSPをセットアップまたは調整して、交通トランクを混雑しているリソースから、またはおそらくより有利なルートに向けてルーティングします。
c. Reconfiguring the logical topology of the network to make it correlate more closely with the spatial traffic distribution using, for example, an underlying path-oriented technology such as MPLS LSPs or optical channel trails.
c. ネットワークの論理トポロジを再構成して、MPLS LSPや光学チャネルトレイルなどの基礎となるパス指向のテクノロジーを使用して、空間トラフィック分布とより密接に相関させるようにします。
* When these schemes are adaptive, they rely on measurement systems. A measurement system monitors changes in traffic distribution, traffic loads, and network resource utilization and then provides feedback to the online or offline TE mechanisms and tools so that they can trigger control actions within the network. The TE mechanisms and tools can be implemented in a distributed or centralized fashion. A centralized scheme may have full visibility into the network state and may produce 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 might not reflect the actual state of the network. It is not an objective of this document to make a recommendation between distributed and centralized schemes; that is a choice that network administrators must make based on their specific needs.
* これらのスキームが適応性がある場合、測定システムに依存します。測定システムは、トラフィックの分布、トラフィック負荷、ネットワークリソースの使用率の変更を監視し、オンラインまたはオフラインのTEメカニズムとツールにフィードバックを提供して、ネットワーク内の制御アクションをトリガーできるようにします。TEメカニズムとツールは、分散または集中化された方法で実装できます。集中型スキームは、ネットワーク状態を完全に可視化し、より最適なソリューションを生成する可能性があります。ただし、集中化されたスキームは単一の障害点になりやすく、分散スキームと同様にスケーリングされない場合があります。さらに、集中型スキームによって利用される情報は古くなり、ネットワークの実際の状態を反映していない可能性があります。このドキュメントの目的は、分散スキームと集中化されたスキームの間に推奨を行うことではありません。これは、ネットワーク管理者が特定のニーズに基づいて行わなければならない選択です。
* Short (minutes or less): This category includes packet-level processing functions and events that are recorded on the order of several round-trip times. It also includes router mechanisms such as passive and active buffer management. All of these mechanisms are used to control congestion or signal congestion to end systems so that they can adaptively regulate the rate at which traffic is injected into the network. A well-known active queue management scheme, especially for responsive traffic such as TCP, is Random Early Detection (RED) [FLJA93]. During congestion (but before the queue is filled), the RED scheme chooses arriving packets to "mark" according to a probabilistic algorithm that takes into account the average queue size. A router that does not utilize Explicit Congestion Notification (ECN) [RFC3168] can simply drop marked packets to alleviate congestion and implicitly notify the receiver about the congestion. On the other hand, if the router and the end hosts support ECN, they can set the ECN field in the packet header, and the end host can act on this information. Several variations of RED have been proposed to support different drop precedence levels in multi-class environments [RFC2597]. RED provides congestion avoidance that is better than or equivalent to Tail-Drop (TD) queue management (drop arriving packets only when the queue is full). Importantly, RED reduces the possibility of retransmission bursts becoming synchronized within the network and improves fairness among different responsive traffic sessions. However, RED by itself cannot prevent congestion and unfairness caused by sources unresponsive to RED, e.g., some misbehaved greedy connections. Other schemes have been proposed to improve performance and fairness in the presence of unresponsive traffic. Some of those schemes (such as Longest Queue Drop (LQD) and Dynamic Soft Partitioning with Random Drop (RND) [SLDC98]) were proposed as theoretical frameworks and are typically not available in existing commercial products, while others (such as Approximate Fair Dropping (AFD) [AFD03]) have seen some implementation. Advice on the use of Active Queue Management (AQM) schemes is provided in [RFC7567]. [RFC7567] recommends self-tuning AQM algorithms like those that the IETF has published in [RFC8290], [RFC8033], [RFC8034], and [RFC9332], but RED is still appropriate for links with stable bandwidth, if configured carefully.
* 短い（分）：このカテゴリには、数回の往復時間の順序で記録されるパケットレベルの処理機能とイベントが含まれます。また、パッシブやアクティブバッファー管理などのルーターメカニズムも含まれています。これらのメカニズムはすべて、輻輳またはシグナルの混雑を制御してシステムを終了させるために使用され、ネットワークにトラフィックが注入される速度を適応的に調節できるようにします。特にTCPなどの応答性のあるトラフィックのためのよく知られたアクティブキュー管理スキームは、ランダムな早期検出（RED）[FLJA93]です。輻輳中（ただし、キューが充填される前）に、赤いスキームは、平均キューサイズを考慮した確率的アルゴリズムに従って「マーク」するパケットを選択します。明示的な輻輳通知（ECN）[RFC3168]を使用しないルーターは、模索パケットを落として混雑を軽減し、渋滞について受信者に暗黙的に通知することができます。一方、ルーターとエンドホストがECNをサポートする場合、PacketヘッダーにECNフィールドを設定でき、エンドホストはこの情報に基づいて行動できます。マルチクラス環境で異なる低下の優先順位レベルをサポートするために、赤のいくつかのバリエーションが提案されています[RFC2597]。REDは、テールドロップ（TD）キュー管理よりも優れている、または同等の混雑回避を提供します（キューがいっぱいの場合にのみ、到着パケットをドロップします）。重要なことに、赤はネットワーク内で再送信バーストが同期される可能性を減らし、異なる応答性のあるトラフィックセッションの公平性を改善します。ただし、赤自体は、赤に反応しない情報源によって引き起こされる混雑や不公平を防ぐことはできません。反応のないトラフィックの存在下でパフォーマンスと公平性を改善するために、他のスキームが提案されています。これらのスキームのいくつか（最長キュードロップ（LQD）やランダムドロップ（RND）[SLDC98]を使用した動的ソフトパーティション化など）は、理論的なフレームワークとして提案されており、通常は既存の市販製品では利用できませんが、他の製品（おおよその公正ドロップなど）（AFD）[AFD03]）いくつかの実装が見られました。アクティブキュー管理（AQM）スキームの使用に関するアドバイスは、[RFC7567]で提供されています。[RFC7567]は、IETFが[RFC8290]、[RFC8033]、[RFC8034]、および[RFC9332]で公開しているような自己調整AQMアルゴリズムを推奨していますが、赤い帯域幅を持つリンクに適しています。
2. Reactive versus Preventive Congestion Management Schemes
2. 反応性と予防輻輳管理スキーム
* Reactive (recovery) congestion management policies react to existing congestion problems. All the policies described above for the short and medium timescales can be categorized as being reactive. They are based on monitoring and identifying congestion problems that exist in the network and on the initiation of relevant actions to ease a situation. Reactive congestion management schemes may also be preventive.
* 反応性（回復）輻輳管理ポリシーは、既存の混雑問題に反応します。短いタイムタイムスケールと中程度のタイムスケールについて上記のすべてのポリシーは、反応的であると分類できます。それらは、ネットワークに存在する混雑の問題の監視と特定に基づいており、状況を容易にするための関連するアクションの開始に基づいています。反応性輻輳管理スキームも予防する可能性があります。
* Preventive (predictive/avoidance) policies take proactive action to prevent congestion based on estimates and predictions of future congestion problems (e.g., traffic matrix forecasts). Some of the policies described for the long and medium timescales fall into this category. Preventive policies 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 future congestion problems. The schemes described for the short timescale can also be used for congestion avoidance because dropping or marking packets before queues actually overflow would trigger corresponding responsive traffic sources to slow down. Preventive congestion management schemes may also be reactive.
* 予防（予測/回避）ポリシーは、将来の渋滞の問題の推定と予測（たとえば、トラフィックマトリックスの予測）に基づいて渋滞を防ぐために積極的な行動を取る。長期および中程度のタイムスケールについて説明したポリシーのいくつかは、このカテゴリに分類されます。予防政策は、必ずしも既存の混雑の問題にすぐに対応するわけではありません。代わりに、トラフィックの需要とワークロードの分布の予測が考慮され、将来の誤った問題を防ぐための行動がとられる場合があります。短いタイムスケールで説明されているスキームは、キューが実際にオーバーフローする前にパケットをドロップまたはマークすると、対応する応答性のあるトラフィックソースをトリガーしてスローダウンするため、うっ血回避にも使用できます。予防渋滞管理スキームも反応する可能性があります。
3. Supply-Side versus Demand-Side Congestion Management Schemes
3. 供給側と需要側の混雑管理スキーム
* Supply-side congestion management policies increase the effective capacity available to traffic in order to control or reduce congestion. This can be accomplished by increasing capacity or by balancing distribution of traffic over the network. Capacity planning aims to provide a physical topology and associated link bandwidths that match or exceed estimated traffic workload and traffic distribution, subject to traffic forecasts and budgetary (or other) constraints. If the actual traffic distribution does not fit the topology derived from capacity planning, then the traffic can be mapped onto the topology by using routing control mechanisms, by applying path-oriented technologies (e.g., MPLS LSPs and optical channel trails) to modify the logical topology or by employing some other load redistribution mechanisms.
* 供給側の輻輳管理ポリシーは、混雑を制御または減少させるために、トラフィックに利用できる有効能力を高めます。これは、容量を増やすか、ネットワーク上のトラフィックの分布のバランスをとることで達成できます。キャパシティプランニングは、トラフィックの予測と予算（またはその他）の制約を条件として、推定されたトラフィックワークロードとトラフィック分布に一致する、またはそれを超える物理トポロジと関連するリンク幅を提供することを目的としています。実際のトラフィック分布が容量計画から得られたトポロジーに適合しない場合、パス指向のテクノロジー（MPLS LSPおよび光学チャネルトレイルなど）を適用して論理を変更することにより、ルーティング制御メカニズムを使用してトラフィックをトポロジにマッピングできます。トポロジーまたは他のいくつかの負荷再配布メカニズムを採用することにより。
* Demand-side congestion management policies control or regulate the offered traffic to alleviate congestion problems. For example, some of the short timescale mechanisms described earlier as well as policing and rate-shaping mechanisms attempt to regulate the offered load in various ways.
* 需要側の輻輳管理ポリシーは、提供されたトラフィックを制御または規制して、混雑の問題を軽減します。たとえば、前述の短いタイムスケールメカニズムのいくつかと、ポリシングおよび速度形成メカニズムは、提供された負荷をさまざまな方法で調節しようとします。
The operational context of Internet TE is characterized by constant changes that 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 TE system and coordinating the activities to accomplish the desired TE objectives. Execution involves measuring and applying corrective or perfective actions to attain and maintain desired TE goals.
インターネットTEの運用コンテキストは、複数のレベルの抽象化で発生する一定の変更によって特徴付けられます。実装コンテキストには、効果的な計画、組織、および実行が必要です。計画の側面には、望ましい目標を達成するために以前のアクションセットを決定することが含まれる場合があります。組織化には、TEシステムのさまざまなコンポーネントに責任を調整および割り当て、目的の目標を達成するためにアクティビティを調整することが含まれます。実行には、望ましい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 must be carried out to optimize the performance of an operational network (see also [RFC2702] and [AWD2]). This process model may be enacted explicitly or implicitly, by a software process or by a human.
このセクションでは、運用コンテキストでインターネットトラフィックエンジニアリングの高レベルの実用的な側面をキャプチャする一般的なプロセスモデルについて説明します。プロセスモデルは、運用ネットワークのパフォーマンスを最適化するために実行する必要がある一連のアクションとして説明されています（[RFC2702]および[AWD2]も参照）。このプロセスモデルは、ソフトウェアプロセスまたは人間によって、明示的または暗黙的に制定される場合があります。
The TE process model is iterative [AWD2]. The four phases of the process model described below are repeated as a continual sequence:
TEプロセスモデルは反復的です[AWD2]。以下に説明するプロセスモデルの4つのフェーズは、継続的なシーケンスとして繰り返されます。
1. Define the relevant control policies that govern the operation of the network.
1. ネットワークの動作を管理する関連する制御ポリシーを定義します。
2. Acquire measurement data from the operational network.
2. 運用ネットワークから測定データを取得します。
3. Analyze the network state and characterize the traffic workload. Proactive analysis identifies potential problems that could manifest in the future. Reactive analysis identifies existing problems and determines their causes.
3. ネットワーク状態を分析し、トラフィックワークロードを特徴付けます。積極的な分析は、将来現れる可能性のある潜在的な問題を特定します。リアクティブ分析は既存の問題を特定し、その原因を決定します。
4. Optimize the performance of the network. This involves a decision process that selects and implements a set of actions from a set of alternatives given the results of the three previous steps. Optimization actions may include the use of techniques to control the offered traffic and to control the distribution of traffic across the network.
4. ネットワークのパフォーマンスを最適化します。これには、以前の3つの手順の結果を考慮して、代替セットから一連のアクションを選択および実装する決定プロセスが含まれます。最適化アクションには、提供されるトラフィックを制御し、ネットワーク全体のトラフィックの分布を制御するための手法の使用が含まれる場合があります。
The key components of the traffic-engineering process model are as follows:
トラフィックエンジニアリングプロセスモデルの重要なコンポーネントは次のとおりです。
1. Measurement is crucial to the TE function. The operational state of a network can only be conclusively determined through measurement. Measurement is also critical to the optimization function because it provides feedback data that is used by TE control subsystems. This data is used to adaptively optimize network performance in response to events and stimuli originating within and outside the network. 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.
1. 測定はTE関数にとって重要です。ネットワークの運用状態は、測定によってのみ最終的に決定できます。測定は、TEコントロールサブシステムで使用されるフィードバックデータを提供するため、最適化関数にとっても重要です。このデータは、ネットワーク内外で発生するイベントや刺激に応じて、ネットワークパフォーマンスを適応的に最適化するために使用されます。TE関数をサポートする測定は、さまざまなレベルの抽象化で発生する可能性があります。たとえば、測定を使用して、パケットレベルの特性、フローレベルの特性、ユーザーレベルまたは顧客レベルの特性、トラフィックアグレージ型特性、コンポーネントレベルの特性、およびネットワーク全体の特性を導き出すことができます。
2. Modeling, analysis, and simulation are important aspects of Internet TE. Modeling involves constructing an abstract or physical representation that depicts relevant traffic characteristics and network attributes. A network model is an abstract representation of the network that captures relevant network features, attributes, and characteristics. Network simulation tools are extremely useful for TE. Because of the complexity of realistic quantitative analysis of network behavior, certain aspects of network performance studies can only be conducted effectively using simulation.
2. モデリング、分析、シミュレーションは、インターネットTEの重要な側面です。モデリングには、関連するトラフィックの特性とネットワーク属性を描写する抽象的または物理的表現の構築が含まれます。ネットワークモデルは、関連するネットワーク機能、属性、および特性をキャプチャするネットワークの抽象表現です。ネットワークシミュレーションツールは、TEにとって非常に便利です。ネットワークの動作の現実的な定量分析の複雑さのために、ネットワークパフォーマンス研究の特定の側面は、シミュレーションを使用して効果的にのみ実施できます。
3. 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.
3. ネットワークパフォーマンスの最適化には、このような問題をソリューションを可能にする概念、ソリューションの識別、およびソリューションの実装を可能にすることにより、ネットワークの問題を解決することが含まれます。ネットワークのパフォーマンスの最適化は、修正または完璧なものになる可能性があります。是正最適化において、目標は、発生した、または初期の問題を改善することです。完璧な最適化では、目標は、明示的な問題が存在せず、予想されない場合でも、ネットワークパフォーマンスを改善することです。
This section presents a short taxonomy of traffic-engineering systems constructed based on TE styles and views as listed below and described in greater detail in the following subsections of this document:
このセクションでは、以下にリストされているTEスタイルとビューに基づいて構築されたトラフィックエンジニアリングシステムの短い分類法を示し、次のドキュメントのサブセクションで詳細に説明します。
* Time-Dependent versus State-Dependent versus Event-Dependent
* 時間依存と状態依存性とイベント依存性
* Offline versus Online
* オフライン対オンライン
* Centralized versus Distributed
* 集中化対分布
* Local versus Global Information
* ローカルとグローバル情報
* Prescriptive versus Descriptive
* 規範的と記述的
* Open-Loop versus Closed-Loop
* オープンループと閉ループ
* Tactical versus Strategic
* 戦術と戦略的
Traffic-engineering methodologies can be classified as time-dependent, state-dependent, or event-dependent. All TE schemes are considered to be dynamic in this document. Static TE implies that no TE methodology or algorithm is being applied -- it is a feature of network planning but lacks the reactive and flexible nature of TE.
トラフィックエンジニアリングの方法論は、時間依存、状態依存、またはイベント依存性として分類できます。このドキュメントでは、すべてのTEスキームが動的であると考えられています。静的TEは、TEの方法論またはアルゴリズムが適用されていないことを意味します。これはネットワーク計画の特徴ですが、TEの反応性と柔軟な性質がありません。
In time-dependent TE, historical information based on periodic variations in traffic (such as time of day) is used to pre-program routing and other TE control mechanisms. Additionally, customer subscription or traffic projection may be used. Pre-programmed routing plans typically change on a relatively long timescale (e.g., daily). Time-dependent algorithms do not attempt to adapt to short-term variations in traffic or changing network conditions. An example of a time-dependent algorithm is a centralized optimizer where the input to the system is a traffic matrix and multi-class QoS requirements as described in [MR99]. Another example of such a methodology is the application of data mining to Internet traffic [AJ19], which enables the use of various machine learning algorithms to identify patterns within historically collected datasets about Internet traffic and to extract information in order to guide decision-making and improve efficiency and productivity of operational processes.
時間依存のTEでは、トラフィックの定期的な変動（時刻など）の定期的な変動に基づく履歴情報は、プログラム前のルーティングやその他のTE制御メカニズムに使用されます。さらに、顧客のサブスクリプションまたはトラフィック予測を使用する場合があります。事前にプログラムされたルーティングプランは、通常、比較的長いタイムスケール（毎日）で変更されます。時間依存のアルゴリズムは、トラフィックやネットワーク条件の変化の短期的な変動に適応しようとはしません。時間依存のアルゴリズムの例は、[MR99]で説明されているように、システムへの入力がトラフィックマトリックスとマルチクラスのQoS要件である集中型オプティマイザーです。このような方法論のもう1つの例は、データマイニングのインターネットトラフィックへの適用[AJ19]です。これにより、さまざまな機械学習アルゴリズムを使用して、歴史的に収集されたデータセット内のインターネットトラフィックに関するパターンを識別し、意思決定をガイドして情報を抽出します。運用プロセスの効率と生産性を向上させます。
State-dependent TE adapts the routing plans based on the current state of the network, which 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 timescale. An example of operating in a relatively short timescale is a load-balancing algorithm described in [MATE]. The state of the network can be based on parameters flooded by the 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. [RFC6374] defines protocol extensions to collect performance measurements from MPLS networks. Another approach is for a management system to gather the relevant information directly from network elements using telemetry data collection publication/subscription techniques [RFC7923]. Timely gathering and distribution of state information is critical for adaptive TE. While time-dependent algorithms are suitable for predictable traffic variations, state-dependent algorithms may be needed to increase network efficiency and to provide resilience to adapt to changes in network state.
国家依存TEは、ネットワークの現在の状態に基づいてルーティングプランを適応させ、実際のトラフィック（つまり、通常のバリエーションからの摂動）のバリエーションに関する追加情報を提供します。制約ベースのルーティングは、比較的長いタイムスケールで動作する状態依存TEの例です。比較的短いタイムスケールで動作する例は、[mate]で説明されている負荷バランスアルゴリズムです。ネットワークの状態は、ルーターによって浸水したパラメーターに基づいています。別のアプローチは、特定のルーターが適応型TEを実行して、そのパスの状態を収集するパスに沿ってプローブパケットを送信することです。[RFC6374]は、MPLSネットワークからパフォーマンス測定を収集するプロトコル拡張機能を定義します。別のアプローチは、管理システムがテレメトリーデータ収集の出版物/サブスクリプションテクニック[RFC7923]を使用して、ネットワーク要素から関連情報を直接収集することです。適応性のある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 they 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 [E.360.1] 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 [RFC6601]. ALB flooding can be resource intensive, since it requires link bandwidth to carry routing protocol link-state advertisements and processor capacity to process those advertisements; in addition, the overhead of the ALB advertisements and their processing can limit the size of the area and AS. Modeling results suggest that event-dependent TE methods could lead to a reduction in ALB flooding overhead without loss of network throughput performance [TE-QoS-ROUTING].
イベント依存のTEメソッドは、TEパスの選択にも使用できます。イベント依存のTEメソッドは、パスが選択される方法で、時間依存および状態依存性TEメソッドとは異なります。これらのアルゴリズムは適応性があり、本質的に分布しており、通常、学習モデルを使用してネットワーク内のTEの良いパスを見つけます。状態依存TEモデルは通常、利用可能なリンク帯域幅（ALB）洪水[E.360.1]を使用しますが、TEパスの選択には、イベント依存のTEメソッドはALB洪水を必要としません。むしろ、イベント依存のTEメソッドは、通常、学習モデル（STT）メソッド[RFC6601]のように、学習モデルによって容量を検索します。ALB洪水は、リンク帯域幅がルーティングプロトコルリンク広告とプロセッサの容量を運ぶためにそれらの広告を処理する必要があるため、リソース集中になる可能性があります。さらに、ALB広告のオーバーヘッドとその処理により、エリアとASのサイズが制限されます。モデリングの結果は、イベント依存のTEメソッドが、ネットワークスループットのパフォーマンスを失うことなくALBフラッディングオーバーヘッドの減少につながる可能性があることを示唆しています[TE-QOS-Routing]。
A fully functional TE system is likely to use all aspects of time-dependent, state-dependent, and event-dependent methodologies as described in Section 4.3.1.
完全に機能するTEシステムは、セクション4.3.1で説明されているように、時間依存、状態依存、およびイベント依存の方法論のすべての側面を使用する可能性があります。
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 relatively simple and fast calculations to select routes, fine-tune the allocations of resources, and perform load balancing.
状態依存アルゴリズムのように、ルーティングプランがネットワーク条件の変化に適応する必要がある場合は、オンライン計算が必要です。オフラインの計算（計算的に要求される可能性がある）とは異なり、オンライン計算は、ルートを選択し、リソースの割り当てを微調整し、負荷分散を実行するための比較的シンプルで高速な計算に向けられています。
Under centralized control, there is a central authority that determines routing plans and perhaps other TE control parameters on behalf of each router. The central authority periodically collects network-state information from all routers and sends routing information to the routers. The update cycle for information exchange in both directions 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 router's 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 exception conditions. Examples of protocol extensions used to advertise network link-state information are defined in [RFC5305], [RFC6119], [RFC7471], [RFC8570], and [RFC8571]. See also Section 5.1.3.9.
分散制御は、ネットワークの状態のルーターの見解に基づいて、各ルーターによるルート選択を自律的に決定します。ネットワーク状態情報は、調査方法を使用してルーターによって取得されるか、リンク状態広告を使用して他のルーターによって定期的に配布される場合があります。ネットワーク状態情報は、例外条件下でも配布される場合があります。ネットワークリンク状態情報の宣伝に使用されるプロトコル拡張の例は、[RFC5305]、[RFC6119]、[RFC7471]、[RFC8570]、および[RFC8571]で定義されています。セクション5.1.3.9も参照してください。
In practice, most TE systems will be a hybrid of central and distributed control. For example, a popular MPLS approach to TE is to use a central controller based on an active, stateful Path Computation Element (PCE) but to use routing and signaling protocols to make local decisions at routers within the network. Local decisions may be able to respond more quickly to network events but may result in conflicts with decisions made by other routers.
実際には、ほとんどのTEシステムは、中央および分散制御のハイブリッドになります。たとえば、TEへの一般的なMPLSアプローチは、アクティブでステートフルなパス計算要素（PCE）に基づいて中央コントローラーを使用することですが、ルーティングとシグナリングプロトコルを使用して、ネットワーク内のルーターでローカル決定を行うことです。ローカルの決定は、ネットワークイベントにより迅速に対応できる可能性がありますが、他のルーターによる決定と競合する可能性があります。
Network operations for TE systems may also use a hybrid of offline and online computation. TE paths may be precomputed based on stable-state network information and planned traffic demands but may then be modified in the active network depending on variations in network state and traffic load. Furthermore, responses to network events may be precomputed offline to allow rapid reactions without further computation or may be derived online depending on the nature of the events.
TEシステムのネットワーク操作は、オフラインおよびオンライン計算のハイブリッドを使用する場合があります。TEパスは、安定した状態ネットワーク情報と計画されたトラフィック需要に基づいて事前計算される場合がありますが、ネットワーク状態とトラフィック負荷の変動に応じて、アクティブネットワークで変更される場合があります。さらに、ネットワークイベントへの応答は、オフラインで事前に計算されて、さらに計算せずに迅速な反応を可能にするか、イベントの性質に応じてオンラインで導き出される場合があります。
As discussed in Section 5.1.2.2, one of the main drivers for Software-Defined Networking (SDN) is a decoupling of the network control plane from the data plane [RFC7149]. However, SDN may also combine centralized control of resources and facilitate application-to-network interaction via an Application Programming Interface (API), such as the one described in [RFC8040]. Combining these features provides a flexible network architecture that can adapt to the network requirements of a variety of higher-layer applications, a concept often referred to as the "programmable network" [RFC7426].
セクション5.1.2.2で説明したように、ソフトウェア定義ネットワーク（SDN）の主なドライバーの1つは、データプレーン[RFC7149]からのネットワーク制御プレーンのデカップリングです。ただし、SDNは、[RFC8040]に記載されているようなアプリケーションプログラミングインターフェイス（API）を介して、リソースの集中制御を組み合わせて、アプリケーションプログラミングインターフェイス（API）を介してネットワーク間インタラクションを促進する場合もあります。これらの機能を組み合わせることで、さまざまな高層アプリケーションのネットワーク要件に適応できる柔軟なネットワークアーキテクチャが提供されます。これは、しばしば「プログラム可能なネットワーク」と呼ばれる概念です[RFC7426]。
The centralized control aspect of SDN helps improve network resource utilization compared with distributed network control, where local policy may often override network-wide optimization goals. In an SDN environment, the data plane forwards traffic to its desired destination. However, before traffic reaches the data plane, the logically centralized SDN control plane often determines the path the application traffic will take in the network. Therefore, the SDN control plane needs to be aware of the underlying network topology, capabilities, and current node and link resource state.
SDNの集中制御の側面は、ローカルポリシーがネットワーク全体の最適化の目標を上書きすることが多い分散ネットワーク制御と比較して、ネットワークリソースの使用率の改善に役立ちます。SDN環境では、データプレーンは希望の目的地にトラフィックを転送します。ただし、トラフィックがデータプレーンに到達する前に、論理的に集中化されたSDNコントロールプレーンは、多くの場合、ネットワークでアプリケーショントラフィックが取るパスを決定します。したがって、SDNコントロールプレーンは、基礎となるネットワークトポロジ、機能、現在のノードとリンクリソース状態を認識する必要があります。
Using a PCE-based SDN control framework [RFC7491], the available network topology may be discovered by running a passive instance of OSPF or IS-IS, or via BGP Link State (BGP-LS) [RFC9552]), to generate a Traffic Engineering Database (TED) (see Section 5.1.3.14). The PCE is used to compute a path (see Section 5.1.3.11) based on the TED and available bandwidth, and further path optimization may be based on requested objective functions [RFC5541]. When a suitable path has been computed, the programming of the explicit network path may be either performed using a signaling protocol that traverses the length of the path [RFC3209] or performed per-hop with each node being directly programmed [RFC8283] by the SDN controller.
PCEベースのSDN制御フレームワーク[RFC7491]を使用して、利用可能なネットワークトポロジは、OSPFまたはIS-ISの受動的インスタンスを実行するか、BGPリンク状態（BGP-LS）[RFC9552]）を介して、トラフィックを生成することにより発見される場合があります。エンジニアリングデータベース（TED）（セクション5.1.3.14を参照）。PCEは、TEDおよび利用可能な帯域幅に基づいてパス（セクション5.1.3.11を参照）を計算するために使用され、さらにパス最適化は要求された目的関数[RFC5541]に基づいている場合があります。適切なパスが計算された場合、明示的なネットワークパスのプログラミングは、パスの長さ[RFC3209]を通過する信号プロトコルを使用して実行されるか、各ノードがSDNNによって直接プログラムされている[RFC8283]を実行して実行できます。コントローラ。
By utilizing a centralized approach to network control, additional network benefits are also available, including Global Concurrent Optimization (GCO) [RFC5557]. A GCO path computation request will simultaneously use the network topology and a set of new path signaling requests, along with their respective constraints, for optimal placement in the network. Correspondingly, a GCO-based computation may be applied to recompute existing network paths to groom traffic and to mitigate congestion.
ネットワーク制御への集中アプローチを利用することにより、グローバルな同時最適化（GCO）[RFC5557]を含む追加のネットワーク利点も利用できます。GCOパス計算要求は、ネットワークに最適な配置のために、ネットワークトポロジと新しいパスシグナル伝達要求とそれぞれの制約を同時に使用します。それに対応して、GCOベースの計算を適用して、既存のネットワークパスを再計算して交通をグルーミングし、混雑を軽減することができます。
Traffic-engineering algorithms may require local and global network-state information.
トラフィックエンジニアリングアルゴリズムには、ローカルおよびグローバルネットワーク状態情報が必要になる場合があります。
Local information is the state of a portion of the domain. Examples include the bandwidth and packet loss rate of a particular path or the state and capabilities of a network link. Local state information may be sufficient for certain instances of distributed control TE.
ローカル情報は、ドメインの一部の状態です。例には、特定のパスの帯域幅とパケット損失率、またはネットワークリンクの状態と機能が含まれます。分散制御TEの特定のインスタンスには、地方の州情報で十分かもしれません。
Global information is the state of the entire TE domain. 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システムも、場合によってはグローバル情報が必要になる場合があります。
TE systems may also be classified as prescriptive or descriptive.
TEシステムは、規範的または記述的に分類される場合があります。
Prescriptive traffic engineering evaluates alternatives and recommends a course of action. Prescriptive TE 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は、既存または予測された異常に対処するための一連の行動を規定しています。完璧な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.
一方、記述交通工学は、ネットワークの状態を特徴付け、特定の行動方針を推奨せずにさまざまなポリシーの影響を評価します。
One way to express a service request is through "intent". Intent-Based Networking aims to produce networks that are simpler to manage and operate, requiring only minimal intervention. Intent is defined in [RFC9315] as follows:
サービスリクエストを表現する1つの方法は、「意図」を使用することです。Intentベースのネットワーキングは、管理と運用がより簡単なネットワークを作成することを目的としており、最小限の介入のみを必要とします。意図は[RFC9315]で次のように定義されています。
A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them.
一連の運用目標（ネットワークが満たすべき）と結果（ネットワークが提供することになっている）は、それらを達成または実装する方法を指定せずに宣言的な方法で定義します。
Intent provides data and functional abstraction so that users and operators do not need to be concerned with low-level device configuration or the mechanisms used to achieve a given intent. This approach can be conceptually easier for a user but may be less expressive in terms of constraints and guidelines.
意図はデータと機能的な抽象化を提供するため、ユーザーとオペレーターが低レベルのデバイス構成や特定の意図を達成するために使用されるメカニズムに関心を持たせる必要がないようにします。このアプローチは、ユーザーにとって概念的に簡単になる可能性がありますが、制約とガイドラインの点ではあまり表現力がありません。
Intent-Based Networking is applicable to TE because many of the high-level objectives may be expressed as intent (for example, load balancing, delivery of services, and robustness against failures). The intent is converted by the management system into TE actions within the network.
意図ベースのネットワーキングは、高レベルの目標の多くが意図として表現される可能性があるため、TEに適用されます（たとえば、負荷分散、サービスの提供、障害に対する堅牢性）。意図は、管理システムによってネットワーク内のTEアクションに変換されます。
Open-loop traffic-engineering control is where control action does not use feedback information from the current network state. However, the control action may use its own local information for accounting purposes.
オープンループトラフィックエンジニアリング制御は、制御アクションが現在のネットワーク状態からフィードバック情報を使用しない場合です。ただし、制御アクションは、会計目的で独自のローカル情報を使用する場合があります。
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 current measurement or recent historical records.
クローズドループトラフィックエンジニアリング制御は、コントロールアクションがネットワーク状態からのフィードバック情報を利用する場所です。フィードバック情報は、現在の測定または最近の歴史的記録の形である場合があります。
Tactical traffic engineering aims to address specific performance problems (such as hotspots) 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 briefly reviews different TE-related approaches proposed and implemented in telecommunications and computer networks using IETF protocols and architectures. These approaches are organized into three categories:
このセクションでは、IETFプロトコルとアーキテクチャを使用して、通信およびコンピューターネットワークで提案および実装されたさまざまなTE関連のアプローチを簡単に確認します。これらのアプローチは、次の3つのカテゴリに編成されています。
* TE mechanisms that adhere to the definition provided in Section 1.2
* セクション1.2で提供されている定義に付着するメカニズム
* Approaches that rely upon those TE mechanisms
* これらのメカニズムに依存するアプローチ
* Techniques that are used by those TE mechanisms and approaches
* これらのメカニズムとアプローチで使用されるテクニック
The discussion is not intended to be comprehensive. It is primarily intended to illuminate existing approaches to TE in the Internet. A historic overview of TE in telecommunications networks was provided in Section 4 of [RFC3272], and Section 4.6 of that document presented an outline of some early approaches to TE conducted in other standards bodies. It is out of the scope of this document to provide an analysis of the history of TE or an inventory of TE-related efforts conducted by other Standards Development Organizations (SDOs).
議論は包括的であることを意図したものではありません。これは主に、インターネット内のTEへの既存のアプローチを照らすことを目的としています。通信ネットワークのTEの歴史的な概要は、[RFC3272]のセクション4で提供され、その文書のセクション4.6は、他の標準団体で実施されるTEに対するいくつかの初期のアプローチの概要を示しました。TEの歴史の分析または他の標準開発組織（SDO）が実施するTE関連の取り組みのインベントリの分析を提供することは、この文書の範囲外です。
This subsection reviews a number of IETF activities pertinent to Internet traffic engineering. Some of these technologies are widely deployed, others are mature but have seen less deployment, and some are unproven or are still under development.
このサブセクションでは、インターネットトラフィックエンジニアリングに関連する多くのIETFアクティビティをレビューします。これらのテクノロジーのいくつかは広く展開されており、他のテクノロジーは成熟していますが、展開が少なくなっており、いくつかは証明されていないか、まだ開発中です。
The IETF developed the Integrated Services (Intserv) model that requires resources, such as bandwidth and buffers, to be reserved a priori for a given traffic flow to ensure that the QoS requested by the traffic flow is satisfied. The Intserv model includes additional components beyond those used in the best-effort model such as packet classifiers, packet schedulers, and admission control. A packet classifier is used to identify flows that are to receive a certain level of service. A packet scheduler handles the scheduling of service to different packet flows to ensure that QoS commitments are met. Admission control is used to determine whether a router has the necessary resources to accept a new flow.
IETFは、帯域幅やバッファーなどのリソースを必要とする統合サービス（INTSERV）モデルを開発し、特定のトラフィックフローの先験的なものを予約して、トラフィックフローによって要求されたQoSが満たされるようにします。INTSERVモデルには、パケット分類器、パケットスケジューラー、アミズミコントロールなどのベストエフォルトモデルで使用されるコンポーネントを超えた追加のコンポーネントが含まれています。パケット分類器は、特定のレベルのサービスを受信するフローを識別するために使用されます。パケットスケジューラは、QoSコミットメントが満たされていることを確認するために、さまざまなパケットフローへのサービスのスケジューリングを処理します。入学制御は、ルーターが新しいフローを受け入れるために必要なリソースを持っているかどうかを判断するために使用されます。
The main issue with the Intserv model has been scalability [RFC2998], especially in large public IP networks that may potentially have millions of active traffic flows in transit concurrently. Pre-Congestion Notification (PCN) [RFC5559] solves the scaling problems of Intserv by using measurement-based admission control (and flow termination to handle failures) between edge nodes. Nodes between the edges of the internetwork have no per-flow operations, and the edge nodes can use the Resource Reservation Protocol (RSVP) per-flow or per-aggregate.
INTSERVモデルの主な問題は、特に同時に輸送中に何百万ものアクティブなトラフィックフローがある可能性がある大規模な公共IPネットワークでのスケーラビリティ[RFC2998]です。事前相合通知（PCN）[RFC5559]は、エッジノード間の測定ベースの入場制御（およびフロー終了を処理するためのフロー終了）を使用することにより、INTSERVのスケーリング問題を解決します。インターネットワークのエッジ間のノードには、フローごとの操作がなく、エッジノードはフローごとにリソース予約プロトコル（RSVP）を使用するか、凝集ごとに使用できます。
A notable feature of the Intserv model is that it requires explicit signaling of QoS requirements from end systems to routers [RFC2753]. RSVP performs this signaling function and is a critical component of the Intserv model. RSVP is described in Section 5.1.3.2.
INTSERVモデルの顕著な特徴は、エンドシステムからルーターへのQoS要件の明示的なシグナル伝達が必要であることです[RFC2753]。RSVPはこのシグナル伝達関数を実行し、INTSVモデルの重要なコンポーネントです。RSVPはセクション5.1.3.2で説明されています。
The goal of Differentiated Services (Diffserv) within the IETF was 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 [RFC2475]. One of the primary motivations for Diffserv was to devise alternative mechanisms for service differentiation in the Internet that mitigate the scalability issues encountered with the Intserv model.
IETF内の差別化されたサービス（diffserv）の目標は、動作凝集体にトラフィックを分類するためのスケーラブルなメカニズムを考案することでした。空間[RFC2475]。DIFFSERVの主な動機の1つは、インターネットモデルで発生したスケーラビリティの問題を軽減するインターネットでのサービス差別化の代替メカニズムを考案することでした。
Diffserv uses the Differentiated Services field in the IP header (the DS field) consisting of six bits in what was formerly known as the Type of Service (TOS) octet. The DS field is used to indicate the forwarding treatment that a packet should receive at a transit node [RFC2474]. Diffserv includes the concept of Per-Hop Behavior (PHB) groups. Using the PHBs, several classes of services can be defined using different classification, policing, shaping, and scheduling rules.
DiffServは、以前はサービスのタイプ（TOS）Octetとして知られていた6ビットで構成されるIPヘッダー（DSフィールド）の差別化されたサービスフィールドを使用します。DSフィールドは、パケットがトランジットノード[RFC2474]で受信するべき転送処理を示すために使用されます。DiffServには、ホップごとの行動（PHB）グループの概念が含まれます。PHBを使用して、さまざまな分類、ポリシング、シェーピング、およびスケジューリングルールを使用して、いくつかのクラスのサービスを定義できます。
For an end user of network services to utilize Diffserv provided by its Internet Service Provider (ISP), it may be necessary for the user to have an SLA with the ISP. An SLA may explicitly or implicitly specify a Traffic Conditioning Agreement (TCA) that defines classifier rules as well as metering, marking, discarding, and shaping rules.
ネットワークサービスのエンドユーザーがインターネットサービスプロバイダー（ISP）から提供されるDIFFSERVを利用するために、ユーザーが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フィールドは、ドメイン間の既存の契約に従って再マイクされる場合があります。
Diffserv allows only a finite number of service classes to be specified 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.
diffservは、DSフィールドで有限数のサービスクラスのみを指定できます。INTSERVモデルに関連するDiffServアプローチの主な利点は、スケーラビリティです。リソースはクラスごとに割り当てられ、州情報の量は、アプリケーションフローの数ではなくクラスの数に比例します。
Once the network has been planned and the packets have been marked at the network edge, the Diffserv model deals with traffic management issues on a per-hop basis. The Diffserv control model consists of a collection of micro-TE control mechanisms. Other TE 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 Diffserv across a complete domain [RFC3086].
ネットワークが計画され、パケットがネットワークエッジでマークされると、DiffServモデルはホップごとにトラフィック管理の問題を扱います。diffserv制御モデルは、マイクロTEコントロールメカニズムのコレクションで構成されています。容量管理（ルーティング制御を含む）などの他のTE機能も、DiffServネットワークで許容できるサービス品質を提供するために必要です。「ドメインごとの行動」の概念は、完全なドメイン[RFC3086]を介したdiffservの概念をよりよく捉えるために導入されています。
Diffserv procedures can also be applied in an MPLS context. See Section 6.8 for more information.
Diffservプロシージャは、MPLSコンテキストでも適用できます。詳細については、セクション6.8を参照してください。
SR Policy [RFC9256] is an evolution of SR (see Section 5.1.3.12) to enhance the TE capabilities of SR. It is a framework that enables instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node.
SRポリシー[RFC9256]は、SRのTE機能を強化するためのSR（セクション5.1.3.12を参照）の進化です。これは、そのノードからのトラフィックステアリングを特定の意図でソースルーティングポリシーを実装するために、ノード上のセグメントの順序付きリストのインスタンス化を可能にするフレームワークです。
An SR Policy is identified through the tuple <headend, color, endpoint>. The headend is the IP address of the node where the policy is instantiated. The endpoint is the IP address of the destination of the policy. The color is an index that associates the SR Policy with an intent (e.g., low latency).
SRポリシーは、tuple <headend、color、endpoint>を通じて識別されます。ヘッドエンドは、ポリシーがインスタンス化されるノードのIPアドレスです。エンドポイントは、ポリシーの宛先のIPアドレスです。色は、SRポリシーを意図（たとえば低遅延）に関連付けるインデックスです。
The headend node is notified of SR Policies and associated SR paths via configuration or by extensions to protocols such as the Path Computation Element Communication Protocol (PCEP) [RFC8664] or BGP [SR-TE-POLICY]. Each SR path consists of a segment list (an SR source-routed path), and the headend uses the endpoint and color parameters to classify packets to match the SR Policy and so determine along which path to forward them. If an SR Policy is associated with a set of SR paths, each is associated with a weight for weighted load balancing. Furthermore, multiple SR Policies may be associated with a set of SR paths to allow multiple traffic flows to be placed on the same paths.
ヘッドエンドノードは、構成を介して、またはパス計算要素通信プロトコル（PCEP）[RFC8664]またはBGP [SR-TE-Policy]などのプロトコルへの拡張を介してSRポリシーと関連するSRパスについて通知されます。各SRパスはセグメントリスト（SRソースルートパス）で構成され、ヘッドエンドはエンドポイントとカラーパラメーターを使用してパケットを分類してSRポリシーに一致するため、どのパスを転送するかを決定します。SRポリシーがSRパスのセットに関連付けられている場合、それぞれが加重負荷分散の重みに関連付けられています。さらに、複数のSRポリシーがSRパスのセットに関連付けられて、複数のトラフィックフローを同じパスに配置できるようにする場合があります。
An SR Binding SID (BSID) may also be associated with each candidate path associated with an SR Policy or with the SR Policy itself. The headend node installs a BSID-keyed entry in the forwarding plane and assigns it the action of steering packets that match the entry to the selected path of the SR Policy. This steering can be done in various ways:
SRバインドSID（BSID）は、SRポリシーまたはSRポリシー自体に関連する各候補パスにも関連付けられている場合があります。ヘッドエンドノードは、転送面にBSIDキーのエントリをインストールし、SRポリシーの選択したパスにエントリを一致させるステアリングパケットのアクションを割り当てます。このステアリングは、さまざまな方法で行うことができます。
SID Steering:
SIDステアリング：
Incoming packets have an active Segment Identifier (SID) matching a local BSID at the headend.
着信パケットには、ヘッドエンドのローカルBSIDと一致するアクティブセグメント識別子（SID）があります。
Per-destination Steering:
設定ごとのステアリング：
Incoming packets match a BGP/Service route, which indicates an SR Policy.
着信パケットは、SRポリシーを示すBGP/サービスルートと一致します。
Per-flow Steering:
フローステアリング：
Incoming packets match a forwarding array (for example, the classic 5-tuple), which indicates an SR Policy.
着信パケットは、SRポリシーを示す転送配列（たとえば、クラシック5タプルなど）と一致します。
Policy-based Steering:
ポリシーベースのステアリング：
Incoming packets match a routing policy, which directs them to an SR Policy.
着信パケットはルーティングポリシーと一致し、SRポリシーに向けられます。
In addition to IP-based TE mechanisms, Layer 4 transport-based TE approaches can be considered in specific deployment contexts (e.g., data centers and multi-homing). For example, the 3GPP defines the Access Traffic Steering, Switching, and Splitting (ATSSS) [ATSSS] service functions as follows:
IPベースのTEメカニズムに加えて、特定の展開コンテキスト（データセンターやマルチホミングなど）でレイヤー4トランスポートベースのTEアプローチを考慮することができます。たとえば、3GPPは、アクセストラフィックステアリング、スイッチング、および分割（ATSSS）[ATSS]サービス機能を次のように定義します。
Access Traffic Steering:
アクセストラフィックステアリング：
This is the selection of an access network for a new flow and the transfer of the traffic of that flow over the selected access network.
これは、新しいフローのためのアクセスネットワークの選択と、選択したアクセスネットワーク上のそのフローのトラフィックの転送です。
Access Traffic Switching:
アクセストラフィックスイッチング：
This is the migration of all packets of an ongoing flow from one access network to another access network. Only one access network is in use at a time.
これは、あるアクセスネットワークから別のアクセスネットワークへの進行中のフローのすべてのパケットの移行です。一度に1つのアクセスネットワークのみが使用されています。
Access Traffic Splitting:
アクセストラフィックの分割：
This is about forwarding the packets of a flow across multiple access networks simultaneously.
これは、複数のアクセスネットワーク全体にフローのパケットを同時に転送することです。
The control plane is used to provide hosts and specific network devices with a set of policies that specify which flows are eligible to use the ATSSS service. The traffic that matches an ATSSS policy can be distributed among the available access networks following one of the following four modes:
コントロールプレーンは、ATSSSサービスを使用する資格があるフローを指定する一連のポリシーをホストと特定のネットワークデバイスに提供するために使用されます。ATSSSポリシーに一致するトラフィックは、次の4つのモードのいずれかに続いて、利用可能なアクセスネットワークに分配できます。
Active-Standby:
Active-Standby：
The traffic is forwarded via a specific access (called "active access") and switched to another access (called "standby access") when the active access is unavailable.
トラフィックは特定のアクセス（「アクティブアクセス」と呼ばれる）を介して転送され、アクティブアクセスが利用できない場合に別のアクセス（「スタンバイアクセス」と呼ばれる）に切り替えられます。
Priority-based:
優先度ベース：
Network accesses are assigned priority levels that indicate which network access is to be used first. The traffic associated with the matching flow will be steered onto the network access with the highest priority until congestion is detected. Then, the overflow will be forwarded over the next highest priority access.
ネットワークアクセスには、最初に使用するネットワークアクセスを示す優先レベルが割り当てられます。一致するフローに関連付けられたトラフィックは、うっ血が検出されるまで、最優先事項でネットワークアクセスに操縦されます。次に、オーバーフローは、次の優先度アクセスに転送されます。
Load-Balancing:
ロードバランス：
The traffic is distributed among the available access networks following a distribution ratio (e.g., 75% to 25%).
トラフィックは、分布比（75％から25％など）に続いて、利用可能なアクセスネットワークに分配されます。
Smallest Delay:
最小の遅延：
The traffic is forwarded via the access that presents the smallest round-trip time (RTT).
トラフィックは、最小の往復時間（RTT）を提示するアクセスを介して転送されます。
For resource management purposes, hosts and network devices support means such as congestion control, RTT measurement, and packet scheduling.
リソース管理の目的で、ホストおよびネットワークデバイスは、混雑制御、RTT測定、パケットスケジューリングなどの手段をサポートします。
For TCP traffic, Multipath TCP [RFC8684] and the 0-RTT Convert Protocol [RFC8803] are used to provide the ATSSS service.
TCPトラフィックの場合、MultiPath TCP [RFC8684]および0-RTT Convert Protocol [RFC8803]を使用してATSSSサービスを提供します。
Multipath QUIC [QUIC-MULTIPATH] and Proxying UDP in HTTP [RFC9298] are used to provide the ATSSS service for UDP traffic. Note that QUIC [RFC9000] supports the switching and steering functions. Indeed, QUIC supports a connection migration procedure that allows peers to change their Layer 4 transport coordinates (IP addresses, port numbers) without breaking the underlying QUIC connection.
MultiPath Quic [Quic-Multipath]およびHTTP [RFC9298]のUDPのプロキシは、UDPトラフィックにATSSサービスを提供するために使用されます。QUIC [RFC9000]は、スイッチング機能とステアリング機能をサポートしていることに注意してください。実際、QUICは、基礎となるQUIC接続を破ることなく、ピアがレイヤー4輸送座標（IPアドレス、ポート番号）を変更できるようにする接続移行手順をサポートしています。
Extensions to the Datagram Congestion Control Protocol (DCCP) [RFC4340] to support multipath operations are defined in [MULTIPATH-DCCP].
Datagramの輻輳制御プロトコル（DCCP）[RFC4340]の拡張マルチパス操作をサポートするための拡張は、[MultiPath-DCCP]で定義されています。
Deterministic Networking (DetNet) [RFC8655] is an architecture for applications with critical timing and reliability requirements. The layered architecture particularly focuses on developing DetNet service capabilities in the data plane [RFC8938]. The DetNet service sub-layer provides a set of Packet Replication, Elimination, and Ordering Functions (PREOF) to provide end-to-end service assurance. The DetNet forwarding sub-layer provides corresponding forwarding assurance (low packet loss, bounded latency, and in-order delivery) functions using resource allocations and explicit route mechanisms.
決定論的ネットワーキング（DETNET）[RFC8655]は、重要なタイミングと信頼性の要件を備えたアプリケーションのアーキテクチャです。階層化されたアーキテクチャは、特にデータプレーン[RFC8938]のデットネットサービス機能の開発に焦点を当てています。Detnet Serviceサブレイヤーは、エンドツーエンドのサービス保証を提供するために、パケットレプリケーション、排除、および順序付け関数（PROF）のセットを提供します。DETNET転送サブレイヤーは、リソースの割り当てと明示的なルートメカニズムを使用して、対応する転送保証（低いパケット損失、境界レイテンシ、および注文内配信）機能を提供します。
The separation into two sub-layers allows a greater flexibility to adapt DetNet capability over a number of TE data plane mechanisms, such as IP, MPLS, and SR. More importantly, it interconnects IEEE 802.1 Time Sensitive Networking (TSN) [RFC9023] deployed in Industry Control and Automation Systems (ICAS).
2つのサブ層への分離により、IP、MPLS、SRなどの多くのTEデータプレーンメカニズムにわたって、デットネット機能をより柔軟に適応させることができます。さらに重要なことは、IEEE 802.1時間敏感なネットワーキング（TSN）[RFC9023]は、業界管理および自動化システム（ICAS）に展開されています。
DetNet can be seen as a specialized branch of TE, since it sets up explicit optimized paths with allocation of resources as requested. A DetNet application can express its QoS attributes or traffic behavior using any combination of DetNet functions described in sub-layers. They are then distributed and provisioned using well-established control and provisioning mechanisms adopted for traffic engineering.
Detnetは、要求されているようにリソースの割り当てを備えた明示的な最適化されたパスを設定するため、TEの専門分野と見なすことができます。DETNETアプリケーションは、サブレイヤーで説明されているDetNet関数の任意の組み合わせを使用して、QOS属性またはトラフィック動作を表現できます。その後、トラフィックエンジニアリングに採用された定評のある制御およびプロビジョニングメカニズムを使用して、配布およびプロビジョニングされます。
In DetNet, a considerable amount of state information is required to maintain per-flow queuing disciplines and resource reservation for a large number of individual flows. This can be quite challenging for network operations during network events, such as faults, change in traffic volume, or reprovisioning. Therefore, DetNet recommends support for aggregated flows; however, it still requires a large amount of control signaling to establish and maintain DetNet flows.
Detnetでは、多数の個々のフローのために、流れごとのキューイングの分野と資源予約を維持するために、かなりの量の州情報が必要です。これは、障害、交通量の変化、または再確認など、ネットワークイベント中のネットワーク操作にとって非常に困難な場合があります。したがって、Detnetは集約されたフローのサポートを推奨しています。ただし、デットネットフローを確立および維持するには、依然として大量の制御信号が必要です。
Note that DetNet might suffer from some of the scalability concerns described for Intserv in Section 5.1.1.1, but the scope of DetNet's deployment scenarios is smaller and therefore less exposed to scaling issues.
Detnetは、セクション5.1.1.1のINTSERVについて説明されているスケーラビリティの懸念のいくつかに苦しむ可能性があることに注意してください。しかし、Detnetの展開シナリオの範囲は小さく、したがってスケーリングの問題にさらされていないことに注意してください。
This document describes various TE mechanisms available in the network. However, in general, distributed applications (particularly, bandwidth-greedy P2P applications that are used for file sharing, for example) cannot directly use those techniques. As per [RFC5693], applications could greatly improve traffic distribution and quality by cooperating with external services that are aware of the network topology. Addressing the Application-Layer Traffic Optimization (ALTO) problem means, on the one hand, deploying an ALTO service to provide applications with information regarding the underlying network (e.g., basic network location structure and preferences of network paths) and, on the other hand, enhancing applications in order to use such information to perform better-than-random selection of the endpoints with which they establish connections.
このドキュメントでは、ネットワークで利用可能なさまざまなTEメカニズムについて説明しています。ただし、一般に、分散アプリケーション（特に、ファイル共有に使用される帯域幅グレディP2Pアプリケーションなど）は、これらの手法を直接使用することはできません。[RFC5693]によると、アプリケーションは、ネットワークトポロジを認識している外部サービスと協力することにより、トラフィックの分布と品質を大幅に改善できます。アプリケーション層のトラフィック最適化（ALTO）の問題に対処することは、一方で、ALTOサービスを展開して、基礎となるネットワークに関する情報（たとえば、基本的なネットワークの位置構造とネットワークパスの設定）を提供することを意味します。、そのような情報を使用して、接続を確立するエンドポイントのランダムよりも優れた選択を実行するためのアプリケーションを強化します。
The basic function of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. [RFC7285] describes a protocol implementing the ALTO services as an information-publishing interface that allows a network to publish its network information to network applications. This information can include network node locations, groups of node-to-node connectivity arranged by cost according to configurable granularities, and end-host properties. The information published by the ALTO Protocol should benefit both the network and the applications. The ALTO Protocol uses a REST-ful design and encodes its requests and responses using JSON [RFC8259] with a modular design by dividing ALTO information publication into multiple ALTO services (e.g., the Map Service, the Map-Filtering Service, the Endpoint Property Service, and the Endpoint Cost Service).
ALTOの基本機能は、ネットワークの抽象マップに基づいています。これらのマップは、単純化されたビューを提供しますが、アプリケーションが効果的に利用するためのネットワークに関する十分な情報を提供します。追加サービスは、マップの上に構築されています。[RFC7285]は、ALTOサービスをネットワークがネットワーク情報をネットワークアプリケーションに公開できる情報発行インターフェイスとして実装するプロトコルを説明しています。この情報には、ネットワークノードの位置、構成可能な粒度に応じてコストで配置されたノード間接続のグループ、およびエンドホストプロパティが含まれます。ALTOプロトコルが公開している情報は、ネットワークとアプリケーションの両方に利益をもたらすはずです。ALTOプロトコルは、REST-FUL DESIGNを使用して、JSON [RFC8259]を使用して、ALTO情報出版物を複数のALTOサービス（マップサービス、マップフィルタリングサービス、エンドポイントプロパティサービスに分割することにより、モジュラー設計でリクエストと応答をエンコードします。、およびエンドポイントコストサービス）。
[RFC8189] defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. [RFC8896] extends the ALTO cost information service so that applications decide not only "where" to connect but also "when". This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. [RFC9439] introduces network performance metrics, including network delay, jitter, packet loss rate, hop count, and bandwidth. The ALTO server may derive and aggregate such performance metrics from BGP-LS (see Section 5.1.3.10), IGP-TE (see Section 5.1.3.9), or management tools and then expose the information to allow applications to determine "where" to connect based on network performance criteria. The ALTO Working Group is evaluating the use of network TE properties while making application decisions for new use cases such as edge computing and data-center interconnect.
[RFC8189]は、ALTOクライアントがALTOフィルター処理されたコストマップとエンドポイントコストマップの単一リクエストでいくつかのコストメトリックを取得できるようにする新しいサービスを定義します。[RFC8896]は、ALTOコスト情報サービスを拡張して、アプリケーションが「どこに」接続するだけでなく、「いつ」を決定するようにします。これは、バルクデータ転送を実行する必要があるアプリケーションに役立ち、たとえばオフピーク時間中にこれらの転送をスケジュールしたいと考えています。[RFC9439]は、ネットワーク遅延、ジッター、パケット損失率、ホップカウント、帯域幅などのネットワークパフォーマンスメトリックを導入します。ALTOサーバーは、このようなパフォーマンスメトリックをBGP-LS（セクション5.1.3.10を参照）、IGP-TE（セクション5.1.3.9を参照）、または管理ツールから導き出して集約し、情報を公開してアプリケーションが「場所」を決定できるようにします。ネットワークパフォーマンス基準に基づいて接続します。ALTOワーキンググループは、ネットワークTEプロパティの使用を評価しながら、エッジコンピューティングやデータセンターの相互接続などの新しいユースケースのアプリケーション決定を行います。
One of the main drivers for SDN [RFC7149] is a decoupling of the network control plane from the data plane. This separation has been achieved for TE networks with the development of MPLS and GMPLS (see Sections 5.1.3.3 and 5.1.3.5, respectively) and the PCE (see Section 5.1.3.11). One of the advantages of SDN is its logically centralized control regime that allows a full view of the underlying networks. Centralized control in SDN helps improve network resource utilization compared with distributed network control.
SDN [RFC7149]の主なドライバーの1つは、データプレーンからのネットワーク制御プレーンのデカップリングです。この分離は、MPLSとGMPL（それぞれセクション5.1.3.3および5.1.3.5を参照）とPCE（セクション5.1.3.11を参照）を開発したTEネットワークで達成されています。SDNの利点の1つは、基礎となるネットワークの完全なビューを可能にする論理的に集中化された制御体制です。SDNの集中制御は、分散ネットワーク制御と比較して、ネットワークリソースの使用率を改善するのに役立ちます。
Abstraction and Control of TE Networks (ACTN) [RFC8453] defines a hierarchical SDN architecture that describes the functional entities and methods for the coordination of resources across multiple domains, to provide composite traffic-engineered services. ACTN facilitates composed, multi-domain connections and provides them to the user. ACTN is focused on:
TEネットワークの抽象化と制御（ACTN）[RFC8453]は、複数のドメインにわたるリソースの調整のための機能的エンティティと方法を説明する階層SDNアーキテクチャを定義し、複合トラフィックエンジニアリングサービスを提供します。Actnは、構成されたマルチドメイン接続を促進し、ユーザーに提供します。Actnは次のことに焦点を当てています
* Abstraction of the underlying network resources and how they are provided to higher-layer applications and customers.
* 基礎となるネットワークリソースの抽象化と、それらがより高い層のアプリケーションと顧客にどのように提供されるか。
* Virtualization of underlying resources for use by the customer, application, or service. The creation of a virtualized environment allows operators to view and control multi-domain networks as a single virtualized network.
* 顧客、アプリケーション、またはサービスが使用するための基礎となるリソースの仮想化。仮想化環境の作成により、オペレーターは単一の仮想化ネットワークとしてマルチドメインネットワークを表示および制御できます。
* Presentation to customers of networks as a virtual network via open and programmable interfaces.
* オープンおよびプログラム可能なインターフェイスを介した仮想ネットワークとしてネットワークの顧客へのプレゼンテーション。
The ACTN managed infrastructure is built from traffic-engineered network resources, which may include statistical packet bandwidth, physical forwarding-plane sources (such as wavelengths and time slots), and forwarding and cross-connect capabilities. The type of network virtualization seen in ACTN allows customers and applications (tenants) to utilize and independently control allocated virtual network resources as if they were physically their own resource. The ACTN network is sliced, with tenants being given a different partial and abstracted topology view of the physical underlying network.
ACTNマネージドインフラストラクチャは、統計パケット帯域幅、物理転送面ソース（波長や時間スロットなど）、転送および相互接続機能を含むトラフィックエンジニアのネットワークリソースから構築されています。ACTNで見られるネットワーク仮想化の種類により、顧客とアプリケーション（テナント）は、まるで自分のリソースであるかのように、割り当てられた仮想ネットワークリソースを利用し、独立して制御できます。ACTNネットワークはスライスされており、テナントには物理的な基礎ネットワークの別の部分的および抽象的なトポロジビューが与えられます。
An IETF Network Slice is a logical network topology connecting a number of endpoints using a set of shared or dedicated network resources [NETWORK-SLICES]. The resources are used to satisfy specific SLOs specified by the consumer.
IETFネットワークスライスは、共有または専用のネットワークリソース[ネットワークスライス]のセットを使用して、多くのエンドポイントを接続する論理ネットワークトポロジです。リソースは、消費者が指定した特定のスロを満たすために使用されます。
IETF Network Slices are not, of themselves, TE constructs. However, a network operator that offers IETF Network Slices is likely to use many TE tools in order to manage their network and provide the services.
IETFネットワークスライスは、それ自体ではありません。ただし、IETFネットワークスライスを提供するネットワークオペレーターは、ネットワークを管理し、サービスを提供するために多くのTEツールを使用する可能性があります。
IETF Network Slices are defined such that they are independent of the underlying infrastructure connectivity and technologies used. From a customer's perspective, an IETF Network Slice looks like a VPN connectivity matrix with additional information about the level of service that the customer requires between the endpoints. From an operator's perspective, the IETF Network Slice looks like a set of routing or tunneling instructions with the network resource reservations necessary to provide the required service levels as specified by the SLOs. The concept of an IETF Network Slice is consistent with an enhanced VPN [ENHANCED-VPN].
IETFネットワークスライスは、使用される基礎となるインフラストラクチャの接続性とテクノロジーに依存しないように定義されています。顧客の観点から見ると、IETFネットワークスライスは、顧客がエンドポイント間で必要とするサービスレベルに関する追加情報を備えたVPN接続マトリックスのように見えます。オペレーターの観点から見ると、IETFネットワークスライスは、SLOで指定された必要なサービスレベルを提供するために必要なネットワークリソース予約を備えた一連のルーティングまたはトンネリング命令のように見えます。IETFネットワークスライスの概念は、強化されたVPN [Enhanced-VPN]と一致しています。
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 case, 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 that 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-TE requirements in IP networks was first described in [RFC2702] and led to developments such as MPLS-TE [RFC3209] as described in Section 5.1.3.3.
IPネットワークのMPLS-TE要件のコンテキスト内での制約ベースのルーティングの概念は、[RFC2702]で最初に説明され、セクション5.1.3.3で説明されているようにMPLS-TE [RFC3209]などの開発につながりました。
Unlike QoS-based routing (for example, see [RFC2386], [MA], and [PERFORMANCE-ROUTING]) that 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 that may include policy restrictions.
QoSベースのルーティング（たとえば、[RFC2386]、[MA]、および[パフォーマンスルーティング]を参照）とは異なり、一般的に個々のトラフィックフローをルーティングする問題に対処して、ネットワークリソースの可用性、制約に従って規定されたフローベースのQOS要件を満たす問題を満たすこと - ベースのルーティングは、トラフィックの集合体とフローに適用でき、ポリシー制限を含む可能性のあるさまざまな制約の対象となる場合があります。
The normal approach to routing in an IGP network relies on the IGPs deriving "shortest paths" over the network based solely on the IGP metric assigned to the links. Such an approach is often limited: traffic may tend to converge toward the destination, possibly causing congestion, and it is not possible to steer traffic onto paths depending on the end-to-end qualities demanded by the applications.
IGPネットワークでのルーティングへの通常のアプローチは、リンクに割り当てられたIGPメトリックのみに基づいて、ネットワーク上に「最短パス」を導き出すIGPに依存しています。このようなアプローチはしばしば制限されています。トラフィックは目的地に向かって収束する傾向があり、おそらく混雑を引き起こす可能性があり、アプリケーションが要求するエンドツーエンドの品質に応じてトラフィックをパスに導くことはできません。
To overcome this limitation, various sorts of TE have been widely deployed (as described in this document), where the TE component is responsible for computing the path based on additional metrics and/or constraints. Such paths (or tunnels) need to be installed in the routers' forwarding tables in addition to, or as a replacement for, the original paths computed by IGPs. The main drawbacks of these TE approaches are the additional complexity of protocols and management and the state that may need to be maintained within the network.
この制限を克服するために、TEコンポーネントが追加のメトリックおよび/または制約に基づいてパスの計算を担当するさまざまな種類のTEが広く展開されています（このドキュメントで説明されています）。このようなパス（またはトンネル）は、IGPSによって計算された元のパスに加えて、またはその代替としてルーターの転送テーブルに設置する必要があります。これらのアプローチの主な欠点は、プロトコルと管理の追加の複雑さと、ネットワーク内で維持する必要がある状態です。
IGP Flexible Algorithms [RFC9350] allow IGPs to construct constraint-based paths over the network by computing constraint-based next hops. The intent of Flexible Algorithms is to reduce TE complexity by letting an IGP perform some basic TE computation capabilities. Flexible Algorithm includes a set of extensions to the IGPs that enable a router to send TLVs that:
IGPフレキシブルアルゴリズム[RFC9350]により、IGPは制約ベースの次のホップを計算することにより、ネットワーク上で制約ベースのパスを構築できます。柔軟なアルゴリズムの意図は、IGPにいくつかの基本的なTE計算機能を実行できるようにすることにより、TEの複雑さを減らすことです。柔軟なアルゴリズムには、ルーターがTLVを送信できるようにするIGPSへの拡張セットが含まれています。
* describe a set of constraints on the topology
* トポロジに関する一連の制約を説明してください
* identify calculation-type
* 計算型を識別します
* describe a metric-type that is to be used to compute the best paths through the constrained topology
* 制約されたトポロジを通して最適なパスを計算するために使用されるメトリックタイプを説明してください
A given combination of calculation-type, metric-type, and constraints is known as a Flexible Algorithm Definition (FAD). A router that sends such a set of TLVs also assigns a specific identifier (the Flexible Algorithm) to the specified combination of calculation-type, metric-type, and constraints.
計算型、メトリックタイプ、および制約の特定の組み合わせは、柔軟なアルゴリズム定義（FAD）として知られています。TLVのこのようなセットを送信するルーターは、計算型、メトリックタイプ、および制約の指定された組み合わせに特定の識別子（フレキシブルアルゴリズム）を割り当てます。
There are two use cases for Flexible Algorithm: in IP networks [RFC9502] and in SR networks [RFC9350]. In the first case, Flexible Algorithm computes paths to an IPv4 or IPv6 address; in the second case, Flexible Algorithms computes paths to a Prefix SID (see Section 5.1.3.12).
柔軟なアルゴリズムには2つのユースケースがあります。IPネットワーク[RFC9502]とSRネットワーク[RFC9350]です。最初のケースでは、Flexible AlgorithmはIPv4またはIPv6アドレスへのパスを計算します。2番目のケースでは、柔軟なアルゴリズムがプレフィックスSIDへのパスを計算します（セクション5.1.3.12を参照）。
Examples of where Flexible Algorithms can be useful include:
柔軟なアルゴリズムが役立つ場所の例は次のとおりです。
* Expansion of the function of IP performance metrics [RFC5664] where specific constraint-based routing (Flexible Algorithm) can be instantiated within the network based on the results of performance measurement.
* 特定の制約ベースのルーティング（フレキシブルアルゴリズム）がパフォーマンス測定の結果に基づいてネットワーク内にインスタンス化できる場合、IPパフォーマンスメトリック[RFC5664]の関数の拡張。
* The formation of an "underlay" network using Flexible Algorithms, and the realization of an "overlay" network using TE techniques. This approach can leverage the nested combination of Flexible Algorithm and TE extensions for IGP (see Section 5.1.3.9).
* 柔軟なアルゴリズムを使用した「アンダーレイ」ネットワークの形成と、TEテクニックを使用した「オーバーレイ」ネットワークの実現。このアプローチは、IGPの柔軟なアルゴリズムとTE拡張機能のネストされた組み合わせを活用できます（セクション5.1.3.9を参照）。
* Flexible Algorithms in SR-MPLS (Section 5.1.3.12) can be used as a base to easily build a TE-like topology without TE components on routers or the use of a PCE (see Section 5.1.3.11).
* SR-MPLS（セクション5.1.3.12）の柔軟なアルゴリズムは、ルーターにTEコンポーネントまたはPCEの使用なしでTEのようなトポロジを簡単に構築するためのベースとして使用できます（セクション5.1.3.11を参照）。
* The support for network slices [NETWORK-SLICES] where the SLOs of a particular IETF Network Slice can be guaranteed by a Flexible Algorithm or where a Filtered Topology [NETWORK-SLICES] can be created as a TE-like topology using a Flexible Algorithm.
* 特定のIETFネットワークスライスのスロが柔軟なアルゴリズムによって保証できるネットワークスライス[ネットワークスライス]のサポート、または柔軟なアルゴリズムを使用してTEのようなトポロジとしてフィルタリングされたトポロジ[ネットワークスライス]を作成できる場合。
RSVP is a soft-state signaling protocol [RFC2205]. 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 (see Section 5.1.1.1) for applications to communicate QoS requirements to the network and for the network to reserve relevant resources to satisfy the QoS requirements [RFC2205].
RSVPはソフトステートシグナル伝達プロトコル[RFC2205]です。マルチキャストフローとユニキャストフローの両方のリソース予約のレシーバーが開始した確立をサポートします。RSVPはもともと、統合サービスフレームワーク内のシグナリングプロトコルとして開発されました（セクション5.1.1.1を参照）。アプリケーションは、QoS要件をネットワークに通信し、ネットワークがQoS要件を満たすための関連リソースを予約するために保護します[RFC2205]。
In RSVP, the traffic sender or source node sends a Path message to the traffic receiver with the same source and destination addresses as the traffic that the sender will generate. The Path message contains:
RSVPでは、トラフィック送信者またはソースノードは、送信者が生成するトラフィックと同じソースと宛先アドレスを持つトラフィックレシーバーにパスメッセージを送信します。パスメッセージには以下が含まれています。
* A sender traffic specification describing the characteristics of the traffic
* トラフィックの特性を説明する送信者トラフィック仕様
* A sender template specifying the format of the traffic
* トラフィックの形式を指定する送信者テンプレート
* An optional advertisement specification that is used to support the concept of One Pass With Advertising (OPWA) [RFC2205]
* 広告で1つのパスの概念をサポートするために使用されるオプションの広告仕様（OPWA）[RFC2205]
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 that 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.
パスに沿ったすべての中間ルーターは、パスメッセージを前方にルーティングプロトコルによって決定される次のホップまで前方に進みます。パスメッセージを受信すると、レシーバーはリソースの予約を要求するために使用されるフロー記述子を含むRESVメッセージで応答します。RESVメッセージは、パスメッセージが通過したパスに沿って反対方向に送信者またはソースノードに移動します。パスに沿ったすべての中間ルーターは、RESVメッセージの予約要求を拒否または受け入れることができます。リクエストが拒否された場合、拒否ルーターはレシーバーにエラーメッセージを送信し、信号プロセスが終了します。要求が受け入れられた場合、リンク帯域幅とバッファースペースがフローに割り当てられ、関連するフロー状態情報がルーターにインストールされます。
One of the issues with the original RSVP specification [RFC2205] was scalability. This was because reservations were required for micro-flows, so that the amount of state maintained by network elements tended to increase linearly with the number of traffic flows. These issues are described in [RFC2961], which also modifies and extends RSVP to mitigate the scaling problems to make RSVP a versatile signaling protocol for the Internet. For example, RSVP has been extended to reserve resources for aggregation of flows [RFC3175], to set up MPLS explicit LSPs (see Section 5.1.3.3), and to perform other signaling functions within the Internet. [RFC2961] also describes a mechanism to reduce the amount of Refresh messages required to maintain established RSVP sessions.
元のRSVP仕様[RFC2205]の問題の1つはスケーラビリティでした。これは、ネットワーク要素によって維持される状態の量がトラフィックフローの数とともに直線的に増加する傾向があるため、マイクロフローに予約が必要だったためです。これらの問題は[RFC2961]で説明されています。これは、RSVPを変更および拡張してスケーリングの問題を軽減して、RSVPをインターネットの多用途のシグナル伝達プロトコルにします。たとえば、RSVPは、流れの集約のためのリソースを予約し[RFC3175]、MPLS明示的なLSPをセットアップし（セクション5.1.3.3を参照）、インターネット内の他のシグナル伝達機能を実行するために拡張されています。[RFC2961]は、確立されたRSVPセッションを維持するために必要な更新メッセージの量を減らすメカニズムについても説明しています。
MPLS is a forwarding scheme that also includes extensions to conventional IP control plane protocols. MPLS extends the Internet routing model and enhances packet forwarding and path control [RFC3031].
MPLSは、従来のIPコントロールプレーンプロトコルへの拡張も含まれる転送スキームです。MPLSはインターネットルーティングモデルを拡張し、パケットの転送とパス制御[RFC3031]を強化します。
At the ingress to an MPLS domain, 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 stack entry is then prepended to each packet according to their FECs. The MPLS label stack entry is 32 bits long and contains a 20-bit label field.
MPLSドメインへの侵入では、LSRSは、パケットのIPヘッダーに掲載された情報と、維持されているローカルルーティング情報の組み合わせなど、さまざまな要因に基づいて、IPパケットを転送等価クラス（FEC）に分類します。LSRS。その後、MPLSラベルスタックエントリは、FECに従って各パケットに加えられます。MPLSラベルスタックエントリの長さは32ビットで、20ビットラベルフィールドが含まれています。
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 (label swap), and the packet may be forwarded to the next LSR. Before a packet leaves an MPLS domain, its MPLS label may be removed (label pop). An LSP is the path between an ingress LSR and an egress LSR 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 the Label Distribution Protocol (LDP) to set up LSPs.
LSRは、インデックスとしてパケットに加えられたラベルをローカルネクストラベル転送エントリ（NHLFE）に使用することにより、転送決定を行います。パケットは、NHLFEで指定されているように処理されます。着信ラベルは、発信ラベル（ラベルスワップ）に置き換えられ、パケットは次のLSRに転送される場合があります。パケットがMPLSドメインを離れる前に、MPLSラベルを削除することができます（ラベルポップ）。LSPは、侵入LSRと、ラベル付きパケットが横断する出力LSRの間のパスです。明示的なLSPのパスは、LSPの発信（イングレス）ノードで定義されます。MPLSは、RSVPやラベル分布プロトコル（LDP）などのシグナル伝達プロトコルを使用してLSPをセットアップできます。
MPLS is a powerful technology for Internet TE because it supports explicit LSPs that allow constraint-based routing to be implemented efficiently in IP networks [AWD2]. The requirements for TE over MPLS are described in [RFC2702]. Extensions to RSVP to support instantiation of explicit LSP are discussed in [RFC3209] and Section 5.1.3.4.
MPLSは、IPネットワークで制約ベースのルーティングを効率的に実装できる明示的なLSPをサポートするため、インターネットTEにとって強力なテクノロジーです[AWD2]。MPL上のTEの要件は[RFC2702]で説明されています。明示的なLSPのインスタンス化をサポートするためのRSVPへの拡張については、[RFC3209]およびセクション5.1.3.4で説明されています。
RSVP-TE is a protocol extension of RSVP (Section 5.1.3.2) for traffic engineering. The base specification is found in [RFC3209]. RSVP-TE enables the establishment of traffic-engineered MPLS LSPs (TE LSPs), using loose or strict paths and taking into consideration network constraints such as available bandwidth. The extension supports signaling LSPs on explicit paths that could be administratively specified or computed by a suitable entity (such as a PCE, Section 5.1.3.11) based on QoS and policy requirements, taking into consideration the prevailing network state as advertised by the IGP extension for IS-IS in [RFC5305], for OSPFv2 in [RFC3630], and for OSPFv3 in [RFC5329]. RSVP-TE enables the reservation of resources (for example, bandwidth) along the path.
RSVP-TEは、トラフィックエンジニアリング用のRSVP（セクション5.1.3.2）のプロトコル拡張です。基本仕様は[RFC3209]にあります。RSVP-TEは、緩いパスまたは厳密なパスを使用し、利用可能な帯域幅などのネットワーク制約を考慮に入れて、トラフィックエンジニアリングMPLS LSP（TE LSP）の確立を可能にします。拡張は、IGP拡張の要件に基づいて適切なエンティティ（PCE、セクション5.1.3.11など）によって管理的に指定または計算できる明示的なパスでのシグナリングLSPをサポートします。[RFC5305]のIS-IS、[RFC3630]のOSPFV2、および[RFC5329]のOSPFv3の場合。RSVP-TEは、パスに沿ってリソース（帯域幅など）の予約を可能にします。
RSVP-TE includes the ability to preempt LSPs based on priorities and uses link affinities to include or exclude links from the LSPs. The protocol is further extended to support Fast Reroute (FRR) [RFC4090], Diffserv [RFC4124], and bidirectional LSPs [RFC7551]. RSVP-TE extensions for support for GMPLS (see Section 5.1.3.5) are specified in [RFC3473].
RSVP-TEには、優先順位に基づいてLSPを先取りする機能が含まれており、リンクアフィニティを使用してLSPからリンクを含めるか除外します。プロトコルはさらに拡張され、Fast Reroute（FRR）[RFC4090]、DiffServ [RFC4124]、および双方向LSP [RFC7551]をサポートします。GMPLSのサポートのためのRSVP-TE拡張機能（セクション5.1.3.5を参照）は[RFC3473]で指定されています。
Requirements for point-to-multipoint (P2MP) MPLS-TE LSPs are documented in [RFC4461], and signaling protocol extensions for setting up P2MP MPLS-TE LSPs via RSVP-TE are defined in [RFC4875], where a P2MP LSP comprises multiple source-to-leaf (S2L) sub-LSPs. To determine the paths for P2MP LSPs, selection of the branch points (based on capabilities, network state, and policies) is key [RFC5671]
ポイントツーマルチポイント（P2MP）MPLS-TE LSPの要件は[RFC4461]に記録されており、RSVP-TEを介してP2MP MPLS-TE LSPをセットアップするためのシグナル伝達プロトコル拡張は[RFC4875]で定義されています。ソースツーリーフ（S2L）サブLSP。P2MP LSPのパスを決定するには、分岐点の選択（機能、ネットワーク状態、およびポリシーに基づく）が重要です[RFC5671]
RSVP-TE has evolved to provide real-time dynamic metrics for path selection for low-latency paths using extensions to IS-IS [RFC8570] and OSPF [RFC7471] based on performance measurements for the Simple Two-Way Active Measurement Protocol (STAMP) [RFC8972] and the Two-Way Active Measurement Protocol (TWAMP) [RFC5357].
RSVP-TEは、IS-IS [RFC8570]およびOSPF [RFC7471]への拡張機能を使用して、低遅延パスのパス選択のリアルタイム動的メトリックを提供するために進化しました。[RFC8972]および双方向活性測定プロトコル（TWAMP）[RFC5357]。
RSVP-TE has historically been used when bandwidth was constrained; however, as bandwidth has increased, RSVP-TE has developed into a bandwidth management tool to provide bandwidth efficiency and proactive resource management.
RSVP-TEは、帯域幅が制約されたときに歴史的に使用されてきました。ただし、帯域幅が増加するにつれて、RSVP-TEは帯域幅管理ツールに発展し、帯域幅の効率とプロアクティブなリソース管理を提供しています。
GMPLS extends MPLS control protocols to encompass time-division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH), Plesiochronous Digital Hierarchy (PDH), and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber) and continues to support packet switching. GMPLS provides a common set of control protocols for all of these layers (including some technology-specific extensions), each of which has a distinct data or forwarding plane. GMPLS covers both the signaling and the routing part of that control plane and is based on the TE extensions to MPLS (see Section 5.1.3.4).
GMPLSはMPLS制御プロトコルを拡張して時間帯（例えば、同期光学ネットワーク /同期デジタル階層（SONET / SDH）、プレシオクロナスデジタル階層（PDH）、光学輸送ネットワーク（OTN）、および光学輸送ネットワーク（OTN））、波長（ラムダス）、および波長、および空間的切り替え（たとえば、発信ポートまたはファイバーへの入力ポートまたはファイバー）、パケットの切り替えをサポートし続けています。GMPLSは、これらすべてのレイヤー（一部のテクノロジー固有の拡張機能を含む）に共通のコントロールプロトコルセットを提供し、それぞれに異なるデータまたは転送面があります。GMPLSは、そのコントロールプレーンのシグナル伝達部分とルーティング部分の両方をカバーし、MPLSのTE延長に基づいています（セクション5.1.3.4を参照）。
In GMPLS [RFC3945], the original MPLS architecture is extended to include LSRs whose forwarding planes rely on circuit switching and therefore cannot forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the switching is based on time slots, wavelengths, or physical ports. These additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of MPLS LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress LSRs [RFC3473].
GMPLS [RFC3945]では、元のMPLSアーキテクチャは、転送面が回路スイッチングに依存しているため、パケットまたはセルヘッダーのいずれかにある情報に基づいてデータを転送できないLSRを含むように拡張されています。具体的には、このようなLSRには、スイッチングが時間スロット、波長、または物理ポートに基づいているデバイスが含まれます。これらの追加は、基本的なLSPプロパティに影響を与えます。ラベルの要求と通信方法、MPLS LSPの単方向性、エラーの伝播方法、および侵入と出口のLSRを同期するために提供される情報[RFC3473]。
The IETF IP Performance Metrics (IPPM) Working Group has developed 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 [RFC2330]. The criteria for performance metrics developed by the IPPM Working Group are described in [RFC2330]. Examples of performance metrics include one-way packet loss [RFC7680], one-way delay [RFC7679], and connectivity measures between two nodes [RFC2678]. Other metrics include second-order measures of packet loss and delay.
IETF IPパフォーマンスメトリック（IPPM）ワーキンググループは、インターネットサービスの品質、パフォーマンス、信頼性を監視するために使用できる標準メトリックのセットを開発しました。これらのメトリックは、ネットワークオペレーター、エンドユーザー、および独立したテストグループによって適用され、ユーザーとサービスプロバイダーに、使用/提供するインターネットコンポーネントクラウドのパフォーマンスと信頼性を一般的に理解することができます[RFC2330]。IPPMワーキンググループによって開発されたパフォーマンスメトリックの基準は、[RFC2330]で説明されています。パフォーマンスメトリックの例には、一元配置パケット損失[RFC7680]、一元配置遅延[RFC7679]、および2つのノード間の接続測定[RFC2678]が含まれます。その他の指標には、パケットの損失と遅延の2次測定が含まれます。
Some of the performance metrics specified by the IPPM Working Group are useful for specifying SLAs. SLAs are sets of SLOs negotiated between users and service providers, wherein each objective is a combination of one or more performance metrics, possibly subject to certain constraints.
IPPMワーキンググループによって指定されたパフォーマンスメトリックの一部は、SLAを指定するのに役立ちます。SLAは、ユーザーとサービスプロバイダーとの間でネゴシエートされたSLOのセットであり、各目標は1つ以上のパフォーマンスメトリックの組み合わせであり、おそらく特定の制約の対象となります。
The IPPM Working Group also designs measurement techniques and protocols to obtain these metrics.
IPPMワーキンググループは、これらのメトリックを取得するための測定技術とプロトコルも設計しています。
The IETF Real Time Flow Measurement (RTFM) Working Group produced an architecture that defines a method to specify traffic flows as well as a number of components for flow measurement (meters, meter readers, and managers) [RFC2722]. 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 [RFC2722], a flow measurement system can be very useful in the following contexts:
IETFリアルタイムフロー測定（RTFM）ワーキンググループは、トラフィックフローを指定する方法と、フロー測定用のコンポーネント（メーター、メーターリーダー、マネージャー）[RFC2722]を定義するアーキテクチャを作成しました。フロー測定システムにより、ネットワークトラフィックフローをさまざまな目的でフローレベルで測定および分析できます。[RFC2722]で述べたように、フロー測定システムは、次のコンテキストで非常に役立ちます。
* understanding the behavior of existing networks
* 既存のネットワークの動作を理解する
* planning for network development and expansion
* ネットワーク開発と拡張の計画
* quantification of network performance
* ネットワークパフォーマンスの定量化
* verifying the quality of network service
* ネットワークサービスの品質の確認
* attribution of network usage to users
* ユーザーへのネットワーク使用の帰属
A flow measurement system consists of meters, meter readers, and managers. A meter observes packets passing through a measurement point, classifies them into groups, accumulates 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 any collection of user applications, hosts, 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 specifications, meter control parameters, and sampling techniques. The instructions received by a meter reader from a manager include the address of the meter whose data are to be collected, the frequency of data collection, and the types of flows to be collected.
フロー測定システムは、メーター、メーターリーダー、マネージャーで構成されています。メーターは、測定ポイントを通過するパケットを観察し、それらをグループに分類し、使用データ（各グループのパケットの数やバイトなど）を蓄積し、使用データをフローテーブルに保存します。グループは、ユーザーアプリケーション、ホスト、ネットワークなどのコレクションを表すことができます。メーターリーダーは、さまざまなメーターから使用データを収集して、分析に利用できるようにすることができます。マネージャーは、メーターとメーターの読者の構成と制御を担当します。マネージャーからメーターが受け取った命令には、フロー仕様、メーター制御パラメーター、サンプリング手法が含まれます。マネージャーからメーターリーダーが受け取った指示には、データを収集するデータの頻度、および収集されるフローのタイプが含まれるメーターのアドレスが含まれます。
IP Flow Information Export (IPFIX) [RFC5470] defines an architecture that is very similar to the RTFM architecture and includes Metering, Exporting, and Collecting Processes. [RFC5472] describes the applicability of IPFIX and makes a comparison with RTFM, pointing out that, architecturally, while RTM talks about devices, IPFIX deals with processes to clarify that multiple of those processes may be co-located on the same machine. The IPFIX protocol [RFC7011] is widely implemented.
IP Flow Information Export（IPFIX）[RFC5470]は、RTFMアーキテクチャに非常によく似たアーキテクチャを定義し、メーター、エクスポート、および収集プロセスを含みます。[RFC5472]はIPFIXの適用可能性を説明し、RTFMとの比較を行い、RTMがデバイスについて語っている間、IPFIXはこれらのプロセスの複数が同じマシンで共同で共同で開催される可能性があることを明確にするためにプロセスを扱っています。IPFIXプロトコル[RFC7011]は広く実装されています。
[RFC3124] provides a set of congestion control mechanisms for the use of transport protocols. It also allows the development of 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.
[RFC3124]は、輸送プロトコルを使用するための一連の混雑制御メカニズムを提供します。また、エンドポイントのアクティブユニキャスト接続のサブセット（「渋滞グループ」と呼ばれる）にわたって、うっ血制御を統合するためのメカニズムの開発を可能にします。混雑マネージャーは、各輻輳グループのパスの状態を継続的に監視しています。マネージャーは、その情報を使用して、その混雑グループの接続の間で帯域幅を分割する方法についてスケジューラに指示します。
The concepts described in [RFC3124] and the lessons that can be learned from that work found a home in HTTP/2 [RFC9113] and QUIC [RFC9000], while [RFC9040] describes TCP control block interdependence that is a core construct underpinning the congestion manager defined in [RFC3124].
[RFC3124]で説明されている概念と、その作業から学べる教訓は、HTTP/2 [RFC9113]およびQUIC [RFC9000]で家を見つけましたが、[RFC9040]は、混雑を支えているコアコンストラクトであるTCPコントロールブロックの相互依存性を説明しています。[RFC3124]で定義されたマネージャー。
[RFC5305] describes the extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support TE. Similarly, [RFC3630] specifies TE extensions for OSPFv2, and [RFC5329] has the same description for OSPFv3.
[RFC5305]は、TEをサポートするための中間システム（IS-IS）プロトコルへの中間システムへの拡張を説明しています。同様に、[RFC3630]はOSPFV2のTE拡張機能を指定し、[RFC5329]はOSPFV3について同じ説明を持っています。
IS-IS and OSPF share the common concept of TE extensions to distribute TE parameters, such as link type and ID, local and remote IP addresses, TE metric, maximum bandwidth, maximum reservable bandwidth, unreserved bandwidth, and admin group. The information distributed by the IGPs in this way can be used to build a view of the state and capabilities of a TE network (see Section 5.1.3.14).
IS-ISとOSPFは、リンクタイプとID、ローカルおよびリモートIPアドレス、TEメトリック、最大帯域幅、最大予約可能帯域幅、予約されていない帯域幅、管理グループなどのTEパラメーターを配布するためのTE拡張機能の共通概念を共有します。この方法でIGPSによって配布された情報は、TEネットワークの状態と能力のビューを構築するために使用できます（セクション5.1.3.14を参照）。
The difference between IS-IS and OSPF is in the details of how they encode and transmit the TE parameters:
IS-ISとOSPFの違いは、TEパラメーターのエンコードと送信方法の詳細にあります。
* IS-IS uses the Extended IS Reachability TLV (type 22), the Extended IP Reachability TLV (type 135), and the Traffic Engineering router ID TLV (type 134). These TLVs use specific sub-TLVs described in [RFC8570] to carry the TE parameters.
* IS-ISは、拡張されたIS Reachability TLV（タイプ22）、拡張IPリーチ可能性TLV（タイプ135）、およびトラフィックエンジニアリングルーターID TLV（タイプ134）を使用します。これらのTLVは、[RFC8570]に記載されている特定のサブTLVを使用して、TEパラメーターを運びます。
* OSPFv2 uses Opaque LSA [RFC5250] type 10, and OSPFv3 uses the Intra-Area-TE-LSA. In both OSPF cases, two top-level TLVs are used (Router Address and Link TLVs), and these use sub-TLVs to carry the TE parameters (as defined in [RFC7471] for OSPFv2 and [RFC5329] for OSPFv3).
* OSPFV2は不透明なLSA [RFC5250]タイプ10を使用し、OSPFV3はAREA-TELSA内を使用します。両方のOSPFケースでは、2つのトップレベルTLVが使用され（ルーターアドレスとリンクTLV）、これらはSub-TLVを使用して、OSPFv2および[RFC5329]の[RFC7471]およびOSPFV3の[RFC7471]で定義されています）を使用します。
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including TE information. This is information typically distributed by IGP routing protocols within the network (see Section 5.1.3.9).
多くの環境では、ネットワークの外部のコンポーネントが、TE情報を含むネットワークトポロジとネットワーク内の接続の現在の状態に基づいて計算を実行するために求められています。これは、通常、ネットワーク内のIGPルーティングプロトコルによって配布される情報です（セクション5.1.3.9を参照）。
BGP (see also Section 7) is one of the essential routing protocols that glues the Internet together. BGP-LS [RFC9552] is a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The mechanism is applicable to physical and virtual IGP links and is subject to policy control.
BGP（セクション7も参照）は、インターネットを接着する重要なルーティングプロトコルの1つです。BGP-LS [RFC9552]は、リンク状態とTE情報をネットワークから収集し、BGPルーティングプロトコルを使用して外部コンポーネントと共有できるメカニズムです。メカニズムは、物理的および仮想IGPリンクに適用され、ポリシー制御の対象となります。
Information collected by BGP-LS can be used, for example, to construct the TED (Section 5.1.3.14) for use by the PCE (see Section 5.1.3.11) or may be used by ALTO servers (see Section 5.1.2.1).
BGP-LSによって収集された情報は、たとえば、PCE（セクション5.1.3.11を参照）で使用するためにTED（セクション5.1.3.14）を構築するために使用できます。
Constraint-based path computation is a fundamental building block for TE in MPLS and GMPLS networks. Path computation in large, multi-domain networks is complex and may require special computational components and cooperation between the elements in different domains. The PCE [RFC4655] is an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
制約ベースのパス計算は、MPLSおよびGMPLSネットワークのTEの基本的な構成要素です。大規模なマルチドメインネットワークでのパス計算は複雑であり、異なるドメインの要素間の特別な計算コンポーネントと協力が必要になる場合があります。PCE [RFC4655]は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）です。
Thus, a PCE can provide a central component in a TE system operating on the TED (see Section 5.1.3.14) with delegated responsibility for determining paths in MPLS, GMPLS, or SR networks. The PCE uses the Path Computation Element Communication Protocol (PCEP) [RFC5440] to communicate with Path Computation Clients (PCCs), such as MPLS LSRs, to answer their requests for computed paths or to instruct them to initiate new paths [RFC8281] and maintain state about paths already installed in the network [RFC8231].
したがって、PCEは、MPLS、GMPLS、またはSRネットワークのパスを決定する委任された責任を持つ、TEDで動作するTEシステムの中心コンポーネントを提供できます（セクション5.1.3.14を参照）。PCEは、PATH計算要素通信プロトコル（PCEP）[RFC5440]を使用して、MPLS LSRSなどのパス計算クライアント（PCCS）と通信して、計算パスのリクエストに応答するか、新しいパス[RFC8281]を開始するよう指示し、維持し、ネットワークにすでにインストールされているパス[RFC8231]について述べてください。
PCEs form key components of a number of TE systems. More information about the applicability of PCEs can be found in [RFC8051], while [RFC6805] describes the application of PCEs to determining paths across multiple domains. PCEs also have potential uses in Abstraction and Control of TE Networks (ACTN) (see Section 5.1.2.2), Centralized Network Control [RFC8283], and SDN (see Section 4.3.2).
PCESは、多くのTEシステムの重要なコンポーネントを形成します。PCEの適用性の詳細については、[RFC8051]に記載されていますが、[RFC6805]は、複数のドメイン間のパスを決定するPCESの適用について説明しています。PCESには、TEネットワークの抽象化と制御（ACTN）（セクション5.1.2.2を参照）、集中ネットワーク制御[RFC8283]、およびSDN（セクション4.3.2を参照）の潜在的な用途もあります。
The SR architecture [RFC8402] leverages the source routing and tunneling paradigms. The path a packet takes is defined at the ingress, and the packet is tunneled to the egress.
SRアーキテクチャ[RFC8402]は、ソースルーティングとトンネルパラダイムを活用します。パケットがとるパスは、イングレスで定義され、パケットは出口にトンネルされています。
In a protocol realization, an ingress node steers a packet using a set of instructions, called "segments", that are included in an SR header prepended to the packet: a label stack in MPLS case, and a series of 128-bit SIDs in the IPv6 case.
プロトコルの実現では、イングレスノードは、「セグメント」と呼ばれる一連の命令を使用してパケットを操縦します。これらは、パケットに加えられたSRヘッダーに含まれています。MPLSケースのラベルスタック、および128ビットのシドのシリーズIPv6ケース。
Segments are identified by SIDs. There are four types of SIDs that are relevant for TE.
セグメントはSIDSによって識別されます。TEに関連する4種類のSIDがあります。
* Prefix SID: A SID that is unique within the routing domain and is used to identify a prefix.
* プレフィックスSID：ルーティングドメイン内で一意で、プレフィックスを識別するために使用されるSID。
* Node SID: A Prefix SID with the "N" bit set to identify a node.
* ノードSID：ノードを識別するために「n」ビットが設定されたプレフィックスSID。
* Adjacency SID: Identifies a unidirectional adjacency.
* 隣接SID：単方向の隣接を識別します。
* Binding SID: A Binding SID has two purposes:
* バインディングSID：バインディングSIDには2つの目的があります。
1. To advertise the mappings of prefixes to SIDs/Labels
1. 接頭辞のマッピングをsids/ラベルに宣伝するには
2. To advertise a path available for a Forwarding Equivalence Class (FEC)
2. 転送等価クラス（FEC）で利用可能なパスを宣伝する
A segment can represent any instruction, topological or service-based. SIDs can be looked up in a global context (domain-wide) as well as in some other contexts (see, for example, "context labels" in Section 3 of [RFC5331]).
セグメントは、トポロジーまたはサービスベースの任意の指示を表すことができます。SIDは、グローバルコンテキスト（ドメイン全体）および他のコンテキストで調べることができます（たとえば、[RFC5331]のセクション3の「コンテキストラベル」を参照）。
The application of policy to SR can make SR into a TE mechanism, as described in Section 5.1.1.3.
セクション5.1.1.3で説明されているように、SRへのポリシーの適用は、SRをTEメカニズムにすることができます。
Bit Index Explicit Replication (BIER) [RFC8279] specifies an encapsulation for multicast forwarding that can be used on MPLS or Ethernet transports. A mechanism known as Tree Engineering for Bit Index Explicit Replication (BIER-TE) [RFC9262] provides a component that could be used to build a traffic-engineered multicast system. BIER-TE does not of itself offer full traffic engineering, and the abbreviation "TE" does not, in this case, refer to traffic engineering.
BITインデックス明示的複製（BIER）[RFC8279]は、MPLSまたはイーサネット輸送で使用できるマルチキャスト転送のカプセル化を指定します。BITインデックス露示レプリケーション（BIER-TE）[RFC9262]のツリーエンジニアリングとして知られるメカニズムは、トラフィックエンジニアリングマルチキャストシステムの構築に使用できるコンポーネントを提供します。Bier-TEはそれ自体が完全な交通工学を提供しておらず、この場合、略語「TE」はトラフィックエンジニアリングを参照しません。
In BIER-TE, path steering is supported via the definition of a bitstring attached to each packet that determines how the packet is forwarded and replicated within the network. Thus, this bitstring steers the traffic within the network and forms an element of a traffic-engineering system. A central controller that is aware of the capabilities and state of the network as well as the demands of the various traffic flows is able to select multicast paths that take account of the available resources and demands. Therefore, this controller is responsible for the policy elements of traffic engineering.
BierTEでは、パスがネットワーク内でどのように転送および複製されるかを決定する各パケットに接続されたビットストリングの定義を介してパスステアリングがサポートされます。したがって、このビットストリングはネットワーク内のトラフィックを操縦し、トラフィックエンジニアリングシステムの要素を形成します。ネットワークの機能と状態、およびさまざまなトラフィックフローの要求を認識している中央コントローラーは、利用可能なリソースと要求を考慮したマルチキャストパスを選択できます。したがって、このコントローラーは、トラフィックエンジニアリングのポリシー要素を担当します。
Resource management has implications for the forwarding plane beyond the steering of packets defined for BIER-TE. These include the allocation of buffers to meet the requirements of admitted traffic and may include policing and/or rate-shaping mechanisms achieved via various forms of queuing. This level of resource control, while optional, is important in networks that wish to support congestion management policies to control or regulate the offered traffic to deliver different levels of service and alleviate congestion problems. It is also important in networks that wish to control latencies experienced by specific traffic flows.
リソース管理は、Bier-TE用に定義されたパケットのステアリングを超えて、転送面に影響を与えます。これらには、認められたトラフィックの要件を満たすためのバッファーの割り当てが含まれ、さまざまな形式のキューイングを介して達成されるポリシングおよび/またはレート形成メカニズムが含まれる場合があります。このレベルのリソース制御は、オプションではありますが、さまざまなレベルのサービスを提供し、混雑の問題を軽減するために、提供されたトラフィックを制御または規制するための混雑管理ポリシーをサポートしたいネットワークでは重要です。また、特定のトラフィックフローが経験するレイテンシーを制御したいネットワークでも重要です。
The network states that are relevant to TE need to be stored in the system and presented to the user. The TED is a collection of all TE information about all TE nodes and TE links in the network. It is an essential component of a TE system, such as MPLS-TE [RFC2702] or GMPLS [RFC3945]. In order to formally define the data in the TED and to present the data to the user, the data modeling language YANG [RFC7950] can be used as described in [RFC8795].
ネットワークは、TEに関連する状態で、システムに保存され、ユーザーに提示される必要があります。TEDは、ネットワーク内のすべてのTEノードとTEリンクに関するすべてのTE情報のコレクションです。これは、MPLS-TE [RFC2702]やGMPLS [RFC3945]など、TEシステムの重要なコンポーネントです。TEDのデータを正式に定義し、ユーザーにデータを提示するために、[RFC8795]で説明されているように、データモデリング言語Yang [RFC7950]を使用できます。
The TE control system needs to have a management interface that is human-friendly and a control interface that is programmable for automation. The Network Configuration Protocol (NETCONF) [RFC6241] and the RESTCONF protocol [RFC8040] provide programmable interfaces that are also human-friendly. These protocols use XML- or JSON-encoded messages. When message compactness or protocol bandwidth consumption needs to be optimized for the control interface, other protocols, such as Group Communication for the Constrained Application Protocol (CoAP) [RFC7390] or gRPC [GRPC], are available, especially when the protocol messages are encoded in a binary format. Along with any of these protocols, the data modeling language YANG [RFC7950] can be used to formally and precisely define the interface data.
TEコントロールシステムには、人間に優しい管理インターフェイスと、自動化のためにプログラム可能な制御インターフェイスが必要です。ネットワーク構成プロトコル（NetConf）[RFC6241]およびRESTCONFプロトコル[RFC8040]は、人間に優しいプログラム可能なインターフェイスを提供します。これらのプロトコルは、XMLまたはJSONエンコードメッセージを使用します。メッセージのコンパクト性またはプロトコル帯域幅消費を制御インターフェイスに最適化する必要がある場合、特にプロトコルメッセージがエンコードされる場合、制約付きアプリケーションプロトコル（COAP）[RFC7390]またはGRPC [GRPC]のグループ通信などの他のプロトコルが利用可能です。バイナリ形式。これらのプロトコルのいずれかに加えて、データモデリング言語Yang [RFC7950]を使用して、インターフェイスデータを正式かつ正確に定義できます。
PCEP [RFC5440] is another protocol that has evolved to be an option for the TE system control interface. PCEP messages are TLV based; they are not defined by a data-modeling language such as YANG.
PCEP [RFC5440]は、TEシステム制御インターフェイスのオプションになるように進化した別のプロトコルです。PCEPメッセージはTLVベースです。それらは、ヤンなどのデータモデリング言語で定義されていません。
The Internet is dominated by client-server interactions, principally web traffic and multimedia streams, although in the future, more sophisticated media servers may become dominant. The location and performance of major information servers have 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 is an application-layer function.
複製された情報サーバーのパフォーマンスを改善するために、多くの動的な負荷バランス技術が考案されています。これらの手法は、クライアントの位置、サーバーの位置、サーバーの相対的利用、異なるネットワークの相対的なパフォーマンス、およびさまざまなネットワークの相対的なパフォーマンスに基づいて動的に選択できるため、空間トラフィックの特性がインターネットでより動的になる可能性があります。ネットワークのさまざまな部分の相対的なパフォーマンス。クライアントへの分散サーバーの割り当てプロセスは、「トラフィック監督」と呼ばれます。アプリケーション層関数です。
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.
複数の地理的に分散した場所でサーバーをクライアントに割り当てるトラフィック方向のスキームは、より効果的な決定を下すために経験的なネットワークパフォーマンス統計を必要とする場合があります。将来的には、ネットワーク測定システムがこのタイプの情報を提供する必要がある場合があります。
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 describes high-level recommendations for traffic engineering in the Internet in general terms.
このセクションでは、インターネット内の交通工学に関する高レベルの推奨事項については、一般的に説明します。
The recommendations describe the capabilities needed to solve a TE problem or to achieve a TE objective. Broadly speaking, these recommendations can be categorized as either functional or non-functional recommendations:
推奨事項は、問題を解決したり、目標を達成するために必要な機能を説明しています。大まかに言えば、これらの推奨事項は、機能的または非機能的な推奨事項のいずれかに分類できます。
* Functional recommendations describe the functions that a traffic-engineering system should perform. These functions are needed to realize TE objectives by addressing traffic-engineering problems.
* 機能的な推奨事項トラフィックエンジニアリングシステムが実行する機能について説明します。これらの関数は、トラフィックエンジニアリングの問題に対処することにより、TEの目標を実現するために必要です。
* Non-functional recommendations relate to the quality attributes or state characteristics of a TE system. These recommendations may contain conflicting assertions and may sometimes be difficult to quantify precisely.
* 非機能的推奨事項は、TEシステムの品質属性または状態特性に関連しています。これらの推奨事項には矛盾する主張が含まれている可能性があり、正確に定量化するのが難しい場合があります。
The subsections that follow first summarize the non-functional requirements and then detail the functional requirements.
以下のサブセクションは、最初に非機能要件を要約し、次に機能的要件を詳述します。
The generic non-functional recommendations for Internet traffic engineering are listed in the paragraphs that follow. 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 TE system to tailor it to a specific operational context.
インターネットトラフィックエンジニアリングに関する一般的な非機能的推奨事項は、以下の段落にリストされています。特定のコンテキストでは、これらの推奨事項の一部は重要である可能性がありますが、他の推奨事項はオプションである可能性があります。したがって、TEシステムの開発段階では、特定の運用コンテキストに合わせて優先順位付けが必要になる場合があります。
Automation:
オートメーション：
Whenever feasible, a TE system should automate as many TE functions as possible to minimize the amount of human effort needed to analyze and control operational networks. Automation is particularly important 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 additionally benefit from feedback from the network that indicates the state of network resources and the current load in the network. Further, placing intelligence into components of the TE system could enable automation to be more dynamic and responsive to changes in the network.
実行可能なときはいつでも、TEシステムは、できるだけ多くのTE機能を自動化して、運用ネットワークを分析および制御するために必要な人間の努力の量を最小限に抑える必要があります。自動化は、ネットワーク運用の人間的側面のコストが高く、ヒューマンエラーによって引き起こされるネットワーク問題のリスクが高いため、大規模なパブリックネットワークでは特に重要です。自動化は、ネットワークリソースの状態とネットワーク内の現在の負荷を示すネットワークからのフィードバックからさらに恩恵を受ける場合があります。さらに、TEシステムのコンポーネントにインテリジェンスを配置すると、自動化がネットワークの変更に対してより動的で応答性が高くなる可能性があります。
Flexibility:
柔軟性：
A TE system should allow for changes in optimization policy. In particular, a TE system should provide sufficient configuration options so that a network administrator can tailor the system to a particular environment. It may also be desirable to have both online and offline TE subsystems that 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システムには、クラスベースのパフォーマンス評価と最適化をサポートするオプションも必要です。
Interoperability:
相互運用性：
Whenever feasible, TE systems and their components should be developed with open standards-based interfaces to allow interoperation with other systems and components.
実行可能なときはいつでも、TEシステムとそのコンポーネントは、他のシステムやコンポーネントとの相互操作を可能にするために、オープン標準ベースのインターフェイスで開発する必要があります。
Scalability:
スケーラビリティ：
Public networks continue to grow rapidly with respect to network size and traffic volume. Therefore, to remain applicable as the network evolves, a TE system should be scalable. 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 number of flows and 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 many network resources when collecting and distributing state information or when exerting control.
パブリックネットワークは、ネットワークサイズとトラフィック量に関して急速に成長し続けています。したがって、ネットワークが進化するにつれて適用可能なままであるため、TEシステムはスケーラブルでなければなりません。特に、TEシステムは、ルーターとリンクの数、およびフローの数とトラフィック量に関して、ネットワークが拡大するため、機能的なままでなければなりません。TEシステムには、スケーラブルなアーキテクチャを持つ必要があり、ネットワーク要素の他の機能やプロセスを逆に損なわないようにし、状態情報を収集および配信したり、制御を行使したりする際にネットワークリソースを消費しすぎないようにしてください。
Security:
安全：
Security is a critical consideration in TE systems. Such systems typically exert control over functional aspects of the network to achieve the desired performance objectives. Therefore, adequate measures must be taken to safeguard the integrity of the TE system. Adequate measures must also be taken to protect the network from vulnerabilities that originate from security breaches and other impairments within the TE system.
セキュリティは、TEシステムにおける重要な考慮事項です。このようなシステムは通常、ネットワークの機能的側面を制御して、望ましいパフォーマンス目標を達成します。したがって、TEシステムの完全性を保護するために、適切な措置を講じる必要があります。また、TEシステム内のセキュリティ侵害やその他の障害に起因する脆弱性からネットワークを保護するためには、適切な対策を講じる必要があります。
Simplicity:
シンプルさ：
A TE system should be as simple as possible. Simplicity in user interface does not necessarily imply that the TE system will use naive algorithms. When complex algorithms and internal structures are used, the user interface should hide such complexities from the network administrator as much as possible.
TEシステムはできるだけ単純でなければなりません。ユーザーインターフェイスのシンプルさは、必ずしもTEシステムが素朴なアルゴリズムを使用することを意味するわけではありません。複雑なアルゴリズムと内部構造を使用する場合、ユーザーインターフェイスは、そのような複雑さをネットワーク管理者から可能な限り隠す必要があります。
Stability:
安定性：
Stability refers to the resistance of the network to oscillate (flap) in a disruptive manner from one state to another, which may result in traffic being routed first one way and then another without satisfactory resolution of the underlying TE issues and with continued changes that do not settle down. Stability is a very important consideration in TE systems that respond to changes in the state of the network. State-dependent TE methodologies typically include a trade-off between responsiveness and stability. It is strongly recommended that when a trade-off between responsiveness and stability is needed, it should be made in favor of stability (especially in public IP backbone networks).
安定性とは、ある状態から別の状態へと破壊的な方法で振動する（フラップ）ネットワークの抵抗を指します。その結果、トラフィックは最初に一方向にルーティングされ、次に基礎となるTEの問題の満足のいく解決や継続的な変更を行うことなく、落ち着かない。安定性は、ネットワークの状態の変化に対応するTEシステムで非常に重要な考慮事項です。状態依存のTE方法論には、通常、応答性と安定性のトレードオフが含まれます。応答性と安定性のトレードオフが必要な場合は、安定性を支持して（特に公共のIPバックボーンネットワークで）行うことを強くお勧めします。
Usability:
使いやすさ：
Usability is a human aspect of TE systems. It refers to the ease with which a TE 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システムを展開および操作できる容易さを指します。一般に、既存のネットワークに容易に展開できるTEシステムを持つことが望ましいです。また、操作と保守が簡単なTEシステムを持つことも望ましいです。
Visibility:
可視性：
Mechanisms should exist as part of the TE system 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) that are determined from network measurements can be used as indicators of prevailing network conditions. The capabilities of the various components of the routing system are other examples of status information that should be observable.
メカニズムは、ネットワークから統計を収集し、これらの統計を分析してネットワークがどれだけ機能しているかを判断するためのTEシステムの一部として存在する必要があります。ネットワーク測定から決定される派生統計（トラフィックマトリックス、リンク利用、遅延、パケット損失、その他のパフォーマンス測定値など）は、一般的なネットワーク条件の指標として使用できます。ルーティングシステムのさまざまなコンポーネントの機能は、観察可能なステータス情報の他の例です。
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 TE routing system is one that takes traffic characteristics and network constraints into account during route selection while maintaining stability.
ルーティング制御は、インターネットトラフィックエンジニアリングの重要な側面です。ルーティングは、スループット、遅延、利用など、ネットワークに関連する主要なパフォーマンス測定の多くに影響を与えます。一般に、効果的なルーティング制御なしで広いエリアネットワークで優れたサービス品質を提供することは非常に困難です。望ましいTEルーティングシステムとは、安定性を維持しながら、ルートの選択中にトラフィックの特性とネットワークの制約を考慮したものです。
Shortest Path First (SPF) IGPs are based on shortest path algorithms and have limited control capabilities for TE [RFC2702] [AWD2]. These limitations include:
最初の最短パス（SPF）IGPは、最短パスアルゴリズムに基づいており、TE [RFC2702] [AWD2]の制御機能が制限されています。これらの制限には以下が含まれます。
1. Pure SPF protocols do not take network constraints and traffic characteristics into account during route selection. For example, IGPs always select the shortest paths based on link metrics assigned by administrators, so load sharing cannot be performed across paths of different costs. Note that link metrics are assigned following a range of operator-selected policies that might reflect preference for the use of some links over others; therefore, "shortest" might not be purely a measure of distance. Using shortest paths to forward traffic may cause the following problems:
1. 純粋なSPFプロトコルは、ルート選択中にネットワークの制約とトラフィック特性を考慮していません。たとえば、IGPは常に管理者が割り当てたリンクメトリックに基づいて最短パスを選択するため、さまざまなコストのパス全体で負荷共有を実行することはできません。リンクメトリックは、他のリンクに対するいくつかのリンクの使用に対する好みを反映する可能性のあるさまざまなオペレーターが選択したポリシーの範囲に従って割り当てられていることに注意してください。したがって、「最短」は純粋に距離の尺度ではないかもしれません。最短パスを使用してトラフィックを転送すると、次の問題が発生する場合があります。
* If traffic from a source to a destination exceeds the capacity of a link along the shortest path, the link (and 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.
* トラフィック需要が時間とともに変化するため、問題も発生する可能性がありますが、ネットワークトポロジとルーティングの構成を迅速に変更することはできません。これにより、ネットワークトポロジとルーティング構成が時間の経過とともに最適になるようになり、その結果、渋滞の問題が持続する可能性があります。
2. The Equal-Cost Multipath (ECMP) capability of SPF IGPs supports sharing of traffic among equal-cost paths. 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. Weighted ECMP (WECMP) (see, for example, [EVPN-UNEQUAL-LB]) provides some mitigation.
2. SPF IGPSの等しいマルチパス（ECMP）機能は、等コストのパス間のトラフィックの共有をサポートします。ただし、ECMPは、最も短いパスの間でトラフィックを可能な限り等しく分割しようとします。一般に、ECMPは、等しいコストパス間で構成可能な負荷共有比をサポートしていません。その結果、パスの1つは、他のソースからのトラフィックも運ぶ可能性があるため、他のパスよりも大幅に多くのトラフィックを運ぶ可能性があります。この状況は、より多くのトラフィックを運ぶ経路に沿って渋滞をもたらす可能性があります。加重ECMP（WECMP）（たとえば、[EVPN-Onequal-LB]を参照）は、いくつかの緩和を提供します。
3. Modifying IGP metrics to control traffic routing tends to have network-wide effects. Consequently, undesirable and unanticipated traffic shifts can be triggered as a result. Work described in Section 8 may be capable of better control [FT00] [FT01].
3. トラフィックルーティングを制御するためにIGPメトリックを変更すると、ネットワーク全体の効果がある傾向があります。したがって、結果として、望ましくないと予期しないトラフィックシフトをトリガーできます。セクション8で説明されている作業は、より良い制御[FT00] [FT01]を制御できる場合があります。
Because of these limitations, capabilities are needed to enhance the routing function in IP networks. Some of these capabilities are summarized below:
これらの制限のため、IPネットワークのルーティング機能を強化するには機能が必要です。これらの機能の一部を以下に要約します。
* Constraint-based routing computes routes to fulfill requirements subject to constraints. This can be useful in public IP backbones with complex topologies. Constraints may include bandwidth, hop count, delay, and administrative policy instruments, such as resource class attributes [RFC2702] [RFC2386]. This makes it possible to select routes that satisfy a given set of requirements. Routes computed by 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バックボーンで役立ちます。制約には、帯域幅、ホップカウント、遅延、およびリソースクラス属性[RFC2702] [RFC2386]などの管理政策手段が含まれます。これにより、特定の一連の要件を満たすルートを選択できます。制約ベースのルーティングによって計算されたルートは、必ずしも最短のパスではありません。制約ベースのルーティングは、MPLSなどの明示的なルーティングをサポートするパス指向のテクノロジーで最適に機能します。
* Constraint-based routing can also be used as a way to distribute traffic onto the infrastructure, including for best-effort traffic. For example, congestion problems caused by uneven traffic distribution may be avoided or reduced by knowing the reservable bandwidth attributes of the network links and by specifying the bandwidth requirements for path selection.
* 制約ベースのルーティングは、ベストエフォルトトラフィックを含むインフラストラクチャにトラフィックを配布する方法としても使用できます。たとえば、ネットワークリンクの予約可能な帯域幅の属性を知ることと、パス選択の帯域幅要件を指定することにより、不均一な交通分布によって引き起こされる混雑の問題は、回避または削減される場合があります。
* A number of enhancements to the link-state IGPs allow them to distribute additional state information required for constraint-based routing. The extensions to OSPF are described in [RFC3630], and the extensions to IS-IS are described in [RFC5305]. Some of the additional topology state information includes link attributes, such as reservable bandwidth and link resource class attribute (an administratively specified property of the link). The resource class attribute concept is defined in [RFC2702]. The additional topology state information is carried in new TLVs and sub-TLVs in IS-IS [RFC5305] or in the Opaque LSA in OSPF [RFC3630].
* リンク状態IGPSの多くの拡張により、制約ベースのルーティングに必要な追加の状態情報を配布できます。OSPFへの拡張は[RFC3630]で説明されており、IS-ISの拡張は[RFC5305]で説明されています。追加のトポロジー状態情報には、予約可能な帯域幅やリンクリソースクラス属性（管理上指定されたリンクのプロパティ）などのリンク属性が含まれています。リソースクラス属性の概念は[RFC2702]で定義されています。追加のトポロジー状態情報は、IS-IS [RFC5305]またはOSPF [RFC3630]の不透明LSAで新しいTLVおよびSub-TLVで伝えられています。
* 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 trade-off between the timeliness of the information flooded and the flooding frequency is typically implemented using a threshold based on the percentage change of the advertised resources to avoid excessive consumption of link bandwidth and computational resources and to avoid instability in the TED.
* 拡張されたリンク状態IGPは、通常のIGPよりも頻繁に情報を浸水させる可能性があります。これは、トポロジーの変化がなくても、留置可能な帯域幅の変化やリンクの親和性が強化されたIGPをトリガーして洪水を開始する可能性があるためです。浸水した情報の適時性と洪水頻度の間のトレードオフは、通常、広告されたリソースのパーセンテージ変更に基づいてしきい値を使用して、リンク帯域幅と計算リソースの過度の消費を回避し、TEDの不安定性を回避するために実装されます。
* 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] and [EVPN-UNEQUAL-LB].
* TEシステムでは、ルーティングサブシステムが複数のパス（等しいコストまたは異なるコストで）間の負荷分散比を構成可能にすることも望ましいです。この機能により、ネットワーク管理者は、ネットワーク全体のトラフィック分布の制御により柔軟性が高まります。特定の状況で混雑を回避/緩和するのに非常に役立ちます。例は、[Xiao]および[evpn-unequal-lb]に記載されています。
* 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 away from its original path to another path (without affecting other traffic paths) allows the traffic to be moved from resource-poor network segments to resource-rich segments. Path-oriented technologies, such as MPLS-TE, inherently support this capability as discussed in [AWD2].
* ルーティングシステムには、この目的のために十分なリソースが存在する場合、他のトラフィックのルートに影響を与えることなく、トラフィックのサブセットのルートを制御する機能も備えている必要があります。この機能により、ネットワーク全体のトラフィックの分布をより洗練した制御が可能になります。たとえば、トラフィックを元のパスから別のパスに移動させる機能（他のトラフィックパスに影響を与えることなく）により、トラフィックをリソースのないネットワークセグメントからリソースが豊富なセグメントに移動できます。MPLS-TEなどのパス指向のテクノロジーは、[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 is 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 that may have been generated 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 4.1.
トラフィックマッピングは、特定の要件を満たすために（事前に確立された）パスへのトラフィックワークロードの割り当てです。したがって、制約ベースのルーティングはパスの選択を扱っていますが、トラフィックマッピングは、制約ベースのルーティングまたは他の手段によって生成された可能性のある確立されたパスへのトラフィックの割り当てを扱います。セクション4.1で説明されているように、トラフィックマッピングは、時間依存または状態依存のメカニズムによって実行できます。
Two important aspects of the traffic mapping function are the ability to establish multiple paths between an originating node and a destination node and the capability to distribute the traffic across those paths according to configured policies. A precondition for this scheme is the existence of flexible mechanisms to partition traffic and then assign the traffic partitions onto the parallel paths (described as "parallel traffic trunks" in [RFC2702]). 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 traffic flow) at the destination node of the parallel paths.
トラフィックマッピング関数の2つの重要な側面は、発信元ノードと宛先ノードの間に複数のパスを確立する機能と、構成されたポリシーに従ってそれらのパス全体にトラフィックを配布する機能です。このスキームの前提条件は、トラフィックを分割してから、トラフィックパーティションを並列パスに割り当てるための柔軟なメカニズムの存在です（[RFC2702]の「並列トラフィックトランク」と呼ばれる）。トラフィックが複数の並列パスに割り当てられている場合、並列パスの宛先ノードで同じアプリケーション（またはトラフィックフロー）に属するパケットの適切な順序付けを確保するために、特別な注意を払うことをお勧めします。
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 use short timescale congestion control mechanisms (such as queue management, scheduling, etc.) to mitigate congestion. Thus, mechanisms that perform the traffic mapping functions complement existing congestion control mechanisms. In an operational network, traffic should be mapped onto the infrastructure such that intra-class and inter-class resource contention are minimized (see Section 2).
トラフィックマッピング関数を実行するメカニズムは、混雑を最小限に抑えるためにトラフィックをネットワークインフラストラクチャにマッピングすることを目的とする必要があります。総トラフィック負荷に対応できない場合、またはルーティングとマッピング機能が交通条件の変化に十分速く反応できない場合、トラフィックマッピングシステムは、短いタイムスケールの混雑制御メカニズム（キュー管理、スケジューリングなど）を使用して緩和する場合があります。混雑。したがって、トラフィックマッピング関数を実行するメカニズムは、既存の輻輳制御メカニズムを補完します。運用ネットワークでは、クラス内およびクラス間のリソース競合が最小化されるように、トラフィックをインフラストラクチャにマッピングする必要があります（セクション2を参照）。
When traffic mapping techniques that depend on dynamic state feedback (e.g., MPLS Adaptive Traffic Engineering (MATE) [MATE] and suchlike) are used, special care must be taken to guarantee network stability.
動的状態フィードバック（例：MPLS適応トラフィックエンジニアリング（MATE）[MATE]など）に依存するトラフィックマッピング手法が使用される場合、ネットワークの安定性を保証するために特別な注意を払う必要があります。
The importance of measurement in TE has been discussed throughout this document. A TE system should include mechanisms to measure and collect statistics from the network to support the TE 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.
TEにおける測定の重要性については、このドキュメント全体で説明しています。TEシステムには、TE機能をサポートするために、ネットワークから統計を測定および収集するメカニズムを含める必要があります。統計の分析を支援するには、追加の機能が必要になる場合があります。これらのメカニズムの作用は、収集された統計の精度と完全性に悪影響を与えるべきではありません。統計データ収集のメカニズムも、ネットワークが進化するにつれてスケーリングできる必要があります。
Traffic statistics may be classified according to long-term or short-term timescales. Long-term traffic statistics are very useful for traffic engineering. Long-term traffic statistics may periodically record network workload (such as hourly, daily, and weekly variations in traffic profiles) as well as traffic trends. Aspects of the traffic statistics may also describe class of service characteristics for a network supporting multiple classes of service. Analysis of the long-term traffic statistics may yield other information such as busy-hour characteristics, traffic growth patterns, persistent congestion problems, hotspots, 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 about the 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内のサイトを表す場合があります。
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 tools, FTP, IGP link-state advertisements, NETCONF/RESTCONF, etc.
トラフィック統計は、短期スケールでネットワークの現在の状態の合理的で信頼できる指標を提供する必要があります。一部の短期トラフィック統計には、リンクの使用率とリンクの混雑ステータスが反映される場合があります。混雑指標の例には、過度のパケット遅延、パケット損失、および高いリソース利用が含まれます。この種の情報を配布するためのメカニズムの例には、SNMP、プローブツール、FTP、IGPリンク状態広告、NetConf/RestConfなどがあります。
The recommendations in Sections 6.2 and 6.3 may be sub-optimal or even ineffective if the amount of traffic flowing on a route or path exceeds the capacity of the resource on that route or path. Several approaches can be used to increase the performance of TE systems:
セクション6.2および6.3の推奨事項は、ルートまたはパスで流れるトラフィックの量がそのルートまたはパスのリソースの容量を超える場合、最適ではないか、効果がない場合があります。TEシステムのパフォーマンスを向上させるために、いくつかのアプローチを使用できます。
* The fundamental approach is some form of planning where traffic is steered onto paths so that it is distributed across the available resources. This planning may be centralized or distributed and must be aware of the planned traffic volumes and available resources. However, this approach is only of value if the traffic that is presented conforms to the planned traffic volumes.
* 基本的なアプローチは、トラフィックがパスに操縦されるため、利用可能なリソース全体に配布される計画の何らかの形式です。この計画は集中化または配布される場合があり、計画された交通量と利用可能なリソースに注意する必要があります。ただし、このアプローチは、提示されたトラフィックが計画されたトラフィックボリュームに準拠している場合にのみ価値があります。
* Traffic flows may be policed at the edges of a network. This is a simple way to ensure that the actual traffic volumes are consistent with the planned volumes. Some form of measurement (see Section 6.4) is used to determine the rate of arrival of traffic, and excess traffic could be discarded. Alternatively, excess traffic could be forwarded as best-effort within the network. However, this approach is only completely effective if the planning is stringent and network-wide and if a harsh approach is taken to disposing of excess traffic.
* トラフィックフローは、ネットワークの端に警察される場合があります。これは、実際のトラフィックボリュームが計画されたボリュームと一致するようにする簡単な方法です。何らかの形の測定（セクション6.4を参照）を使用して、トラフィックの到着速度を決定し、過剰なトラフィックを破棄することができます。あるいは、過剰なトラフィックは、ネットワーク内で最高のエフォルトとして転送される可能性があります。ただし、このアプローチは、計画が厳しくネットワーク全体で、過剰なトラフィックの処分に厳しいアプローチが取られている場合にのみ完全に効果的です。
* Resource-based admission control is the process whereby network nodes decide whether to grant access to resources. The basis for the decision on a packet-by-packet basis is the determination of the flow to which the packet belongs. This information is combined with policy instructions that have been locally configured or installed through the management or control planes. The end result is that a packet may be allowed to access (or use) specific resources on the node if, and only if, the flow to which the packet belongs conforms to the policy.
* リソースベースの入場制御は、ネットワークノードがリソースへのアクセスを許可するかどうかを決定するプロセスです。パケットごとの決定の基礎は、パケットが属するフローの決定です。この情報は、管理プレーンまたはコントロールプレーンを介してローカルで構成またはインストールされているポリシー指示と組み合わされます。最終的な結果は、パケットがポリシーに適合する場合にのみ、パケットがノード上の特定のリソースにアクセス（または使用）できる場合にのみ許可される可能性があります。
Combining some elements of all three of these measures is advisable to achieve a better TE system.
これらの3つすべての要素を組み合わせることで、より良いTEシステムを実現することをお勧めします。
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 is an issue of great concern within the Internet community due to the demand 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 TE used to 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. A number of tools and techniques have been developed to enable network survivability, including MPLS Fast Reroute [RFC4090], Topology Independent Loop-free Alternate Fast Reroute for Segment Routing [SR-TI-LFA], RSVP-TE Extensions in Support of End-to-End GMPLS Recovery [RFC4872], and GMPLS Segment Recovery [RFC4873].
ネットワークの生存性とは、障害の存在下でサービスの継続性を維持するネットワークの機能を指します。これは、ネットワークの障害から迅速に回復し、回復後に既存のサービスに必要なQOを維持することによって達成できます。ミッションクリティカルなトラフィック、リアルタイムトラフィック、およびインターネット上のその他の優先順位のトラフィックを運ぶという要求により、インターネットコミュニティ内での生存性は大きな懸念事項です。ネットワークのアーキテクチャ、設計、および動作に冗長性を組み込むことにより、より信頼性の高いネットワーク要素を開発することにより、デバイスレベルで生存性に対処できます。IPネットワーク（特にパブリックIPネットワーク）を制御するために使用されるTEのアーキテクチャ、設計、および運用には、堅牢性と生存性の哲学を採用することをお勧めします。さまざまなコンテキストが異なるレベルの生存性を必要とする可能性があるため、ネットワークの生存性をサポートするために開発されたメカニズムは、さまざまなニーズに合わせて調整できるように柔軟にする必要があります。MPLS Fast Reroute [RFC4090]、セグメントルーティングのためのトポロジ独立したループフリーの代替高速リルート[SR-TI-LFA]、rsvp-TEエクステンションのエンド - エンドのサポートのRSVP-TEエクステンションなど、ネットワークの生存性を可能にするために、多くのツールと技術が開発されました。To End GMPLS回復[RFC4872]、およびGMPLSセグメントリカバリ[RFC4873]。
The impact of service outages varies significantly for different service classes depending on the duration of the outage, which can vary from milliseconds (with minor service impact) to seconds (with possible call drops for IP telephony and session timeouts for connection-oriented transactions) to minutes and hours (with potentially considerable social and business impact). Outages of different durations have different impacts depending on the nature of the traffic flows that are interrupted.
サービス停止の影響は、停止期間によって異なるサービスクラスで大きく異なります。これは、ミリ秒（マイナーなサービスインパクト付き）から秒（IPテレフォニーのコールドロップの可能性があり、接続指向のトランザクションのセッションタイムアウト）までさまざまです。数分と時間（潜在的にかなりの社会的およびビジネスへの影響があります）。さまざまな期間の停止は、中断される交通フローの性質に応じて異なる影響を及ぼします。
Failure protection and restoration capabilities are available in multiple layers as network technologies have continued to evolve. Optical networks are capable of providing dynamic ring and mesh restoration functionality at the wavelength level. 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 Ethernet.
ネットワークテクノロジーが進化し続けているため、障害保護と復元機能は複数のレイヤーで利用できます。光ネットワークは、波長レベルで動的リングとメッシュの修復機能を提供できます。SONET/SDHレイヤーでは、自動保護スイッチング（APS）と自己修復リングとメッシュアーキテクチャで生存性機能が提供されます。同様の機能は、イーサネットなどのレイヤー2テクノロジーによって提供されます。
Rerouting is 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. Path-oriented technologies such as MPLS [RFC3469] can be used to enhance the survivability of IP networks in a potentially cost-effective manner.
再ルーティングは、IPレイヤーで使用され、リンクとノードの停止に続いてサービスを復元します。IPレイヤーでの再ルーティングは、ルーティングの収束期間後に発生します。MPLS [RFC3469]などのパス指向のテクノロジーを使用して、IPネットワークの生存性を潜在的に費用対効果の高い方法で強化できます。
An important aspect of multi-layer survivability is that technologies at different layers may provide protection and restoration capabilities at different granularities in terms of timescales and at different bandwidth granularities (from the level of packets to that of wavelengths). Protection and restoration capabilities can also be sensitive to different service classes and different network utility models. 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.
多層の生存性の重要な側面は、異なる層の技術が、タイムスケールおよび異なる帯域幅の粒度（パケットのレベルから波長のレベルまで）で異なる粒度で保護と修復能力を提供する可能性があることです。保護および修復機能は、さまざまなサービスクラスやさまざまなネットワークユーティリティモデルにも敏感です。ネットワークの生存性が合理的なコストで維持されるように、複数のレイヤーにわたって異なる保護と復元機能を凝集的に調整することは、困難な作業です。異なるレイヤーのネットワークが異なる管理ドメインに属している可能性があるため、レイヤー全体での保護と回復の調整が常に実行可能であるとは限りません。
Some of the general recommendations for protection and restoration coordination are as follows:
保護と回復の調整に関する一般的な推奨事項のいくつかは次のとおりです。
* Protection and restoration capabilities from different layers should be coordinated to provide network survivability in a flexible and cost-effective manner. Avoiding duplication of functions in different 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. The order of timing of restoration triggers from different layers is another way to coordinate multi-layer protection/restoration.
* さまざまなレイヤーからの保護と回復機能を調整して、柔軟で費用対効果の高い方法でネットワークの生存性を提供する必要があります。異なる層での機能の重複を回避することは、調整を実現する1つの方法です。アラームのエスカレーションや下層から高層へのその他の断層指標も、調整された方法で実行される場合があります。異なる層からの修復トリガーのタイミングの順序は、多層保護/修復を調整するもう1つの方法です。
* Network capacity reserved in one layer to provide protection and restoration is not available to carry traffic in a higher layer: it is not visible as spare capacity in the higher layer. Placing protection/restoration functions in many layers may increase redundancy and robustness, but it can result in significant inefficiencies in network resource utilization. Careful planning is needed to balance the trade-off between the desire for survivability and the optimal use of resources.
* 保護と修復を提供するために1つのレイヤーに予約されているネットワーク容量は、より高いレイヤーのトラフィックを運ぶために利用できません。高レイヤーの予備容量としては見えません。多くの層に保護/修復機能を配置すると、冗長性と堅牢性が向上する可能性がありますが、ネットワークリソースの利用には大きな非効率性が発生する可能性があります。生存可能性とリソースの最適な使用とのトレードオフのバランスをとるには、慎重な計画が必要です。
* It is generally desirable to have protection and restoration schemes that are intrinsically bandwidth efficient.
* 一般に、本質的に帯域幅効率的な保護および修復スキームを持つことが望ましいです。
* Failure notifications throughout the network should be timely and reliable if they are to be acted on as triggers for effective protection and restoration actions.
* 効果的な保護と復元アクションのためにトリガーとして機能する場合、ネットワーク全体の障害通知はタイムリーで信頼性が必要です。
* Alarms and other fault monitoring and reporting capabilities should be provided at the right network layers so that the protection and restoration actions can be taken in those layers.
* アラームやその他の障害監視および報告機能は、それらのレイヤーで保護および修復アクションを実行できるように、適切なネットワークレイヤーで提供する必要があります。
Because MPLS is path-oriented, it has the potential to provide faster and more predictable protection and restoration capabilities than conventional hop-by-hop routed IP systems. Protection types for MPLS networks can be divided into four categories:
MPLSはパス指向であるため、従来のホップバイホップルーティングIPシステムよりも、より速く、より予測可能な保護と復元機能を提供する可能性があります。MPLSネットワークの保護タイプは、4つのカテゴリに分類できます。
Link Protection:
リンク保護：
The objective of link protection is to protect an LSP from the failure of a given link. Under link protection, a protection or backup LSP (the secondary LSP) follows a path that is disjoint from the path of the working or operational LSP (the primary LSP) at the particular link where link protection is required. When the protected link fails, traffic on the working LSP is switched to the protection LSP at the headend of the failed link. As a local repair method, link protection can be fast. This form of protection may be most appropriate in situations where some network elements along a given path are known to be less reliable than others.
リンク保護の目的は、LSPを特定のリンクの障害から保護することです。リンク保護下では、保護またはバックアップLSP（セカンダリLSP）は、リンク保護が必要な特定のリンクの作業LSPまたは運用LSP（プライマリLSP）の経路からばらばらのパスに従います。保護されたリンクが失敗すると、動作するLSPのトラフィックは、失敗したリンクのヘッドエンドで保護LSPに切り替えられます。ローカル修理方法として、リンク保護は高速になる可能性があります。この形式の保護は、特定のパスに沿ったいくつかのネットワーク要素が他のパスよりも信頼性が低いことが知られている状況で最も適切な場合があります。
Node Protection:
ノード保護：
The objective of node protection is to protect an LSP from the failure of a given node. Under node protection, the secondary LSP follows a path that is disjoint from the path of the primary LSP at the particular node where node protection is required. The secondary LSP is also disjoint from the primary LSP at all links attached to the node to be protected. When the protected node fails, traffic on the working LSP is switched over to the protection LSP at the upstream LSR directly connected to the failed node. Node protection covers a slightly larger part of the network compared to link protection but is otherwise fundamentally the same.
ノード保護の目的は、特定のノードの障害からLSPを保護することです。ノード保護下では、セカンダリLSPは、ノード保護が必要な特定のノードのプライマリLSPのパスからばらばらのパスに従います。セカンダリLSPは、保護されているノードに接続されたすべてのリンクでプライマリLSPからもばらばらです。保護されたノードが失敗すると、動作するLSPのトラフィックは、故障したノードに直接接続された上流のLSRの保護LSPに切り替えられます。ノード保護は、リンク保護と比較してネットワークのわずかに大きい部分をカバーしますが、それ以外の場合は根本的に同じです。
Path Protection:
パス保護：
The goal of LSP path protection (or end-to-end protection) is to protect an LSP from any failure 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 of ingress or egress LSR. Additionally, path protection may be more efficient in terms of resource usage than link or node protection applied at every hop along the path. However, path protection may be slower than link and node protection because the fault notifications have to be propagated further.
LSPパス保護（またはエンドツーエンドの保護）の目標は、ルーティングされたパスに沿った障害からLSPを保護することです。パス保護の下で、保護LSPの経路は、動作LSPの経路から完全にばらばらになります。パス保護の利点は、バックアップLSPが、侵入または出口LSRの障害を除き、パスに沿ったすべての可能なリンクおよびノード障害から動作LSPを保護することです。さらに、パスに沿ったすべてのホップで適用されるリンクまたはノード保護よりも、リソースの使用に関してパス保護はより効率的になる場合があります。ただし、障害通知をさらに伝播する必要があるため、パス保護はリンクおよびノード保護よりも遅くなる場合があります。
Segment Protection:
セグメント保護：
An MPLS domain may be partitioned into multiple subdomains (protection domains). Path protection is applied to the path of each LSP as it crosses the domain from its ingress to the domain to where it egresses the 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 end-to-end path protection because recovery generally occurs closer to the fault, and the notification doesn't have to propagate as far.
MPLSドメインは、複数のサブドメイン（保護ドメイン）に分割される場合があります。パス保護は、イングレスからドメインにドメインを越えてドメインを出力する場所にドメインを通過するため、各LSPのパスに適用されます。LSPが複数の保護ドメインを通過する場合、ドメイン内の保護メカニズムは、ドメイン内にあるLSPのセグメントを保護するだけで済みます。通常、回復は障害に近づいているため、セグメントの保護は一般にエンドツーエンドのパス保護よりも高速になり、通知を伝播する必要はありません。
See [RFC3469] and [RFC6372] for a more comprehensive discussion of MPLS-based recovery.
MPLSベースの回復のより包括的な議論については、[RFC3469]および[RFC6372]を参照してください。
Another issue to consider is the concept of protection options. We use notation such as "m:n protection", where m is the number of protection LSPs used to protect n working LSPs. In all cases except 1+1 protection, the resources associated with the protection LSPs can be used to carry preemptable best-effort traffic when the working LSP is functioning correctly.
考慮すべきもう1つの問題は、保護オプションの概念です。「m：n保護」などの表記を使用します。ここで、MはN作業LSPを保護するために使用される保護LSPの数です。1 1保護を除くすべての場合において、保護LSPに関連するリソースを使用して、作業LSPが正しく機能している場合に、先制的なベストエフォルトトラフィックを運ぶことができます。
1:1 protection:
1：1保護：
One working LSP is protected/restored by one protection LSP. Traffic is sent only on the protected LSP until the protection/restoration event switches the traffic to the protection LSP.
1つの作業LSPは、1つの保護LSPによって保護/復元されます。保護/修復イベントがトラフィックを保護LSPに切り替えるまで、トラフィックは保護されたLSPでのみ送信されます。
1:n protection:
1：n保護：
One protection LSP is used to protect/restore n working LSPs. Traffic is sent only on the n protected working LSPs until the protection/restoration event switches the traffic from one failed LSP to the protection LSP. Only one failed LSP can be restored at any time.
1つの保護LSPは、動作するLSPを保護/復元するために使用されます。トラフィックは、保護/修復イベントが1つの失敗したLSPから保護LSPにトラフィックを切り替えるまで、保護された作業LSPでのみ送信されます。故障したLSPはいつでも復元できます。
n:1 protection:
n：1保護：
One working LSP is protected/restored by n protection LSPs, possibly with load splitting across the protection LSPs. This may be especially useful when it is not feasible to find one path for the backup that can satisfy the bandwidth requirement of the primary LSP.
1つの作業LSPは、保護LSPを介して荷重分割により、n保護LSPによって保護/復元されます。これは、プライマリLSPの帯域幅要件を満たすことができるバックアップの1つのパスを見つけることができない場合に特に役立ちます。
1+1 protection:
1 1保護：
Traffic is sent concurrently on both the working LSP and a protection LSP. The egress LSR selects one of the two LSPs based on local policy (usually based on traffic integrity). When a fault disrupts the traffic on one LSP, the egress switches to receive traffic from the other LSP. This approach is expensive in how it consumes network but recovers from failures most rapidly.
トラフィックは、作業LSPと保護LSPの両方で同時に送信されます。出力LSRは、ローカルポリシーに基づいて2つのLSPのいずれかを選択します（通常はトラフィックの完全性に基づいています）。障害が1つのLSPのトラフィックを破壊すると、出口は他のLSPからトラフィックを受信するように切り替わります。このアプローチは、ネットワークを消費する方法は高価ですが、障害から最も急速に回復します。
Networks are often implemented as layers. A layer relationship may represent the interaction between technologies (for example, an IP network operated over an optical network) or the relationship between different network operators (for example, a customer network operated over a service provider's network). Note that a multi-layer network does not imply the use of multiple technologies, although some form of encapsulation is often applied.
ネットワークは多くの場合、レイヤーとして実装されます。レイヤー関係は、テクノロジー（たとえば、光ネットワークを介して動作するIPネットワーク）または異なるネットワークオペレーター間の関係（たとえば、サービスプロバイダーのネットワークで動作する顧客ネットワーク）間の相互作用を表す場合があります。多層ネットワークは複数のテクノロジーの使用を意味しないことに注意してください。ただし、何らかの形のカプセル化が適用されることがよくあります。
Multi-layer traffic engineering presents a number of challenges associated with scalability and confidentiality. These issues are addressed in [RFC7926], which discusses the sharing of information between domains through policy filters, aggregation, abstraction, and virtualization. That document also discusses how existing protocols can support this scenario with special reference to BGP-LS (see Section 5.1.3.10).
多層交通エンジニアリングは、スケーラビリティと機密性に関連する多くの課題を提示します。これらの問題は[RFC7926]で対処されており、ポリシーフィルター、集約、抽象化、仮想化を介したドメイン間の情報の共有について説明しています。このドキュメントでは、既存のプロトコルがBGP-LSを特に参照してこのシナリオをどのようにサポートできるかについても説明します（セクション5.1.3.10を参照）。
PCE (see Section 5.1.3.11) is also a useful tool for multi-layer networks as described in [RFC6805], [RFC8685], and [RFC5623]. Signaling techniques for multi-layer TE are described in [RFC6107].
PCE（セクション5.1.3.11を参照）は、[RFC6805]、[RFC8685]、および[RFC5623]に記載されているように、多層ネットワークに有用なツールです。多層TEのシグナル伝達技術は[RFC6107]に記載されています。
See also Section 6.6 for examination of multi-layer network survivability.
マルチレイヤーネットワークの生存性の調査については、セクション6.6も参照してください。
Increasing requirements to support multiple classes of traffic in the Internet, such as best-effort and mission-critical data, call for IP networks to differentiate traffic according to some criteria and to give preferential treatment to certain types of traffic. Large numbers of flows can be aggregated into a few behavior aggregates based on some criteria based on 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パケットヘッダー内の共通フィールドの観点から、共通のパフォーマンス要件に基づいて、いくつかの基準に基づいて、いくつかの基準に基づいて、多数のフローをいくつかの動作集計に集約できます。
Differentiated Services (Diffserv) [RFC2475] can be used to ensure that SLAs defined to differentiate between traffic flows are met. Classes of service can be supported in a Diffserv environment by concatenating Per-Hop Behaviors (PHBs) along the routing path. A PHB is the forwarding behavior that a packet receives at a Diffserv-compliant node, and it can be configured at each router. PHBs are delivered using buffer-management and packet-scheduling mechanisms and require that the ingress nodes use traffic classification, marking, policing, and shaping.
差別化されたサービス（DIFFSERV）[RFC2475]を使用して、トラフィックフローを区別するために定義されたSLAが満たされていることを確認できます。サービスのクラスは、ルーティングパスに沿ってホップごとの動作（PHB）を連結することにより、Diffserv環境でサポートできます。PHBは、パケットがdiffservに準拠したノードで受信する転送動作であり、各ルーターで構成できます。PHBは、バッファー管理およびパケットスケジューリングメカニズムを使用して配信され、イングレスノードがトラフィック分類、マーキング、ポリシング、およびシェーピングを使用する必要があります。
TE can complement Diffserv to improve utilization of network resources. TE can be operated on an aggregated basis across all service classes [RFC3270] or on a per-service-class basis. The former is used to provide better distribution of the traffic load over the network resources (see [RFC3270] for detailed mechanisms to support aggregate TE). The latter case is discussed below since it is specific to the Diffserv environment, with so-called Diffserv-aware traffic engineering [RFC4124].
TEは、ネットワークリソースの利用を改善するためにdiffservを補完できます。TEは、すべてのサービスクラス[RFC3270]またはサービスごとのベースで集約されたベースで動作することができます。前者は、ネットワークリソース上のトラフィック負荷のより良い分布を提供するために使用されます（TEをサポートする詳細なメカニズムについては、[RFC3270]を参照）。後者のケースは、Diffserv-Awareの交通工学[RFC4124]を使用して、Diffserv環境に固有であるため、以下で説明します。
For some Diffserv networks, it may be desirable to control the performance of some service classes by enforcing 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:
一部のDiffServネットワークの場合、各サービスクラスが貢献したトラフィックワークロードとそのサービスクラスに割り当てられたネットワークリソースの量との間の関係を実施することにより、一部のサービスクラスのパフォーマンスを制御することが望ましい場合があります。たとえば、需要とリソースの割り当ての間の関係は、次のような組み合わせを使用して実施できます。
* TE mechanisms on a per-service-class basis that enforce the relationship between the amount of traffic contributed by a given service class and the resources allocated to that class.
* TEメカニズムは、特定のサービスクラスによって寄与するトラフィックの量とそのクラスに割り当てられたリソースとの関係を実施するサービスごとのクラスベースでのメカニズムです。
* Mechanisms that dynamically adjust the resources allocated to a given service class to relate to the amount of traffic contributed by that service class.
* 特定のサービスクラスに割り当てられたリソースを動的に調整するメカニズムは、そのサービスクラスが寄与するトラフィックの量に関連するものです。
It may also be desirable to limit the performance impact of high-priority traffic on relatively low-priority traffic. This can be achieved, for example, by 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 varies significantly from router to router, it may not be enough to rely on conventional IGP routing protocols or on TE mechanisms that are not sensitive to different service classes. Instead, it may be desirable to perform TE, 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ルーティングプロトコルや、異なるサービスクラスに敏感ではないTEメカニズムに依存するだけでは不十分な場合があります。代わりに、サービスごとのベースで、特にルーティング制御およびマッピング機能を実行することが望ましい場合があります。MPLとDiffServの両方をサポートするドメインでこれを達成する1つの方法は、クラス固有のLSPを定義し、各クラスのトラフィックをそのサービスクラスに対応する1つ以上のLSPにマッピングすることです。特定のポリシーに従って、特定のサービスクラスに対応するLSPをルーティングおよび保護/復元することができます。
Performing TE on a per-class basis may require per-class parameters to be distributed. It is common to have some classes share some aggregate constraints (e.g., maximum bandwidth requirement) without enforcing the constraint on each individual class. These classes can be grouped into class types, and per-class-type parameters can be distributed to improve scalability. This 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:
クラスごとにTEを実行するには、一人当たりのパラメーターを分散する必要があります。一部のクラスに、個々のクラスの制約を強制せずに、いくつかのクラスがいくつかの集計制約（例：最大帯域幅要件）を共有することが一般的です。これらのクラスはクラスタイプにグループ化でき、スケーラビリティを改善するためにクラスごとのパラメーターを分散できます。これにより、同じクラスタイプのクラス間でより良い帯域幅共有が可能になります。クラスタイプは、次の2つの条件を満たすクラスのセットです。
* Classes in the same class type have common aggregate requirements to satisfy required performance levels.
* 同じクラスタイプのクラスには、必要なパフォーマンスレベルを満たすための共通の集計要件があります。
* There is no requirement to be enforced at the level of an individual class in the class type. Note that it is, nevertheless, still possible 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.
* クラスタイプの個々のクラスのレベルで実施する要件はありません。それにもかかわらず、同じクラスタイプのクラスにいくつかの優先度ポリシーを実装して、先制優先度を使用してクラス型帯域幅への優先アクセスを可能にすることができることに注意してください。
See [RFC4124] for detailed requirements on Diffserv-aware TE.
Diffserv-Aware TEの詳細な要件については、[RFC4124]を参照してください。
Offline and online (see Section 4.2) TE considerations are of limited utility if the network cannot be controlled effectively to implement the results of TE decisions and to achieve the desired network performance objectives.
オフラインおよびオンライン（セクション4.2を参照）TEの考慮事項は、TEの決定の結果を実装し、望ましいネットワークパフォーマンス目標を達成するためにネットワークを効果的に制御できない場合、有用性が限られています。
Capacity augmentation is a coarse-grained solution to TE issues. However, it is simple, may be applied through creating parallel links that form part of an ECMP scheme, and may be advantageous if bandwidth is abundant and cheap. However, bandwidth is not always abundant and cheap, and additional capacity might not always be the best solution. Adjustments of administrative weights and other parameters associated with routing protocols provide finer-grained control, but this approach is difficult to use and imprecise because of the way the routing protocols interact across the network.
容量の増強は、TEの問題に対する粗粒のソリューションです。ただし、ECMPスキームの一部を形成する並列リンクを作成することで適用される可能性があり、帯域幅が豊富で安価な場合に有利になる可能性があります。ただし、帯域幅は必ずしも豊富で安価ではなく、追加の容量が必ずしも最良のソリューションではないかもしれません。ルーティングプロトコルに関連する管理ウェイトおよびその他のパラメーターの調整は、より細かい粒度の制御を提供しますが、このアプローチは、ルーティングプロトコルがネットワーク全体で相互作用する方法のために使用するのが難しく、不正確です。
Control mechanisms can be manual (e.g., static configuration), partially automated (e.g., scripts), or fully automated (e.g., policy-based management systems). Automated mechanisms are particularly useful in large-scale networks. Multi-vendor interoperability can be facilitated by standardized management tools (e.g., YANG models) to support the control functions required to address TE objectives.
制御メカニズムは、手動（静的構成など）、部分的に自動化された（たとえば、スクリプト）、または完全に自動化されます（ポリシーベースの管理システムなど）。自動化されたメカニズムは、大規模なネットワークで特に役立ちます。マルチベンダーの相互運用性は、TE目的に対処するために必要な制御機能をサポートするために、標準化された管理ツール（Yangモデルなど）によって促進できます。
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 attacks).
ネットワーク制御機能は、ネットワーク障害の時点で正しく動作するために必要であることが多いため、安全で信頼性が高く、安定している必要があります（たとえば、ネットワークの混雑や攻撃中）。
Inter-domain TE is concerned with performance optimization for traffic that originates in one administrative domain and terminates in a different one.
ドメイン間TEは、1つの管理ドメインに由来し、別のドメインで終了するトラフィックのパフォーマンスの最適化に関係しています。
BGP [RFC4271] is the standard exterior gateway protocol used to exchange routing information between ASes in the Internet. BGP includes a decision process that calculates the preference for routes to a given destination network. There are two fundamental aspects to inter-domain TE using BGP:
BGP [RFC4271]は、インターネット内のASE間のルーティング情報を交換するために使用される標準の外部ゲートウェイプロトコルです。BGPには、特定の宛先ネットワークへのルートの選好を計算する決定プロセスが含まれています。BGPを使用して、ドメイン間TEには2つの基本的な側面があります。
Route Propagation:
ルート伝播：
Controlling the import and export of routes between ASes and controlling the redistribution of routes between BGP and other protocols within an AS.
ASEの間のルートの輸入と輸出の制御と、AS内のBGPと他のプロトコル間のルートの再分配を制御します。
Best-path selection:
ベストパスセレクション：
Selecting the best path when there are multiple candidate paths to a given destination network. This is performed by the BGP decision process, which selects the preferred exit points out of an AS toward specific destination networks by taking a number of different considerations into account. The BGP path selection process can be influenced by manipulating the attributes associated with the process, including NEXT_HOP, LOCAL_PREF, AS_PATH, ORIGIN, MULTI_EXIT_DISC (MED), IGP metric, etc.
特定の宛先ネットワークへの複数の候補パスがある場合、最適なパスを選択します。これは、多くの異なる考慮事項を考慮して、特定の宛先ネットワークに向けてASから優先される出口ポイントを選択するBGP決定プロセスによって実行されます。BGPパスの選択プロセスは、next_hop、local_pref、as_path、origin、multi_exit_disc（med）、igp metricなどを含むプロセスに関連付けられた属性を操作することで影響を受ける可能性があります。
Most BGP implementations provide constructs that facilitate the implementation of complex BGP policies based on pre-configured logical conditions. These can be used to control import and export of incoming and outgoing routes, control redistribution of routes between BGP and other protocols, and influence the selection of best paths by manipulating the attributes (either standardized or local to the implementation) associated with the BGP decision process.
ほとんどのBGP実装は、事前に構成された論理条件に基づいて複雑なBGPポリシーの実装を促進する構成要素を提供します。これらを使用して、着信ルートと発信ルートの輸入と輸出を制御し、BGPと他のプロトコル間のルートの再分配を制御し、BGPの決定に関連する属性（標準化されたまたは局所的またはローカル）を操作することにより、最良のパスの選択に影響を与えることができますプロセス。
When considering inter-domain TE with BGP, note that the outbound traffic exit point is controllable, whereas the interconnection point where inbound traffic is received typically is not. Therefore, it is up to each individual network to implement TE strategies that deal with the efficient delivery of outbound traffic from its customers to its peering points. The vast majority of TE policy is based on a "closest exit" strategy, which offloads inter-domain traffic at the nearest outbound peering point towards the destination AS. Most methods of manipulating the point at which inbound traffic enters are either ineffective or not accepted in the peering community.
BGPでドメイン間TEを検討する場合、アウトバウンドトラフィック出口ポイントは制御可能であることに注意してください。一方、インバウンドトラフィックが受信される相互接続ポイントは通常そうではありません。したがって、顧客からピアリングポイントへのアウトバウンドトラフィックの効率的な配信に対処するTE戦略を実装するのは、個々のネットワーク次第です。TEポリシーの大部分は、「最も近い出口」戦略に基づいており、ドメイン間トラフィックを目的地に向かって最も近いアウトバウンドピアリングポイントでオフロードします。インバウンドトラフィックが入るポイントを操作するほとんどの方法は、ピアリングコミュニティでは効果がないか、受け入れられていません。
Inter-domain TE with BGP is generally effective, but it is usually applied in a trial-and-error fashion because a TE system usually only has a view of the available network resources within one domain (an AS in this case). A systematic approach for inter-domain TE requires cooperation between the domains. Further, what may be considered a good solution in one domain may not necessarily be a good solution in another. Moreover, it is generally considered inadvisable for one domain to permit a control process from another domain to influence the routing and management of traffic in its network.
BGPとのドメイン間TEは一般に効果的ですが、通常、TEシステムには1つのドメイン内の利用可能なネットワークリソース（この場合のように）のみのビューのみがあるため、通常は試行錯誤の方法で適用されます。ドメイン間TEの体系的なアプローチには、ドメイン間の協力が必要です。さらに、あるドメインで良い解決策と見なされることは、必ずしも別のドメインでは良い解決策ではないかもしれません。さらに、あるドメインが別のドメインから制御プロセスを許可して、ネットワーク内のトラフィックのルーティングと管理に影響を与えることは、一般的には容認できないと考えられています。
MPLS-TE tunnels (LSPs) can add a degree of flexibility in the selection of exit points for inter-domain routing by applying the concept of relative and absolute metrics. 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 and the peering point via a TE tunnel and assigning the TE tunnel a metric that is smaller than the IGP cost to all other peering points. RSVP-TE protocol extensions for inter-domain MPLS and GMPLS are described in [RFC5151].
MPLS-TEトンネル（LSP）は、相対的および絶対メトリックの概念を適用することにより、ドメイン間ルーティングの出口ポイントの選択にある程度の柔軟性を追加できます。BGP属性がBGP決定プロセスがIGPメトリックに依存してドメイン間トラフィックの出口ポイントを選択するように定義されている場合、特定のピアネットワークに運命づけられているドメイン間トラフィックを選択して、TEを確立して特定の出口ポイントを好むように作成できます。ルーターの間のトンネルは、TEトンネルを介して選択とピアリングポイントを作成し、TEトンネルを他のすべてのピアリングポイントのIGPコストよりも小さいメトリックに割り当てます。ドメイン間MPLおよびGMPLのRSVP-TEプロトコル拡張は[RFC5151]で説明されています。
Similarly 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 AS to another.
ドメイン内のTEと同様に、トラフィックマトリックスを導き出してトラフィックの量を別のものに描写できる場合、ドメイン間TEが最適に行われます。
Layer 4 multipath transport protocols are designed to move traffic between domains and to allow some influence over the selection of the paths. To be truly effective, these protocols would require visibility of paths and network conditions in other domains, but that information may not be available, might not be complete, and is not necessarily trustworthy.
レイヤー4マルチパス輸送プロトコルは、ドメイン間のトラフィックを移動し、パスの選択に何らかの影響を与えるように設計されています。本当に効果的であるために、これらのプロトコルは他のドメインでのパスとネットワーク条件の可視性を必要としますが、その情報は利用できず、完全ではなく、必ずしも信頼できるわけではありません。
This section provides an overview of some TE practices in IP networks. The focus is on aspects of 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ネットワークのいくつかのTEプラクティスの概要を説明します。焦点は、運用コンテキストでのルーティング関数の制御の側面にあります。ここでの意図は、一般的に使用されるプラクティスの概要を提供することです。議論は網羅的であることを意図していません。
Service providers apply many of the TE mechanisms described in this document to optimize the performance of their IP networks, although others choose to not use any of them. These techniques include capacity planning, including adding ECMP options, for long timescales; routing control using IGP metrics and MPLS, as well as path planning and path control using MPLS and SR for medium timescales; and traffic management mechanisms for short timescales.
サービスプロバイダーは、このドキュメントに記載されているTEメカニズムの多くを適用して、IPネットワークのパフォーマンスを最適化しますが、それらのいずれも使用しないことを選択します。これらの手法には、長いタイムスケールのECMPオプションの追加を含む容量計画が含まれます。IGPメトリックとMPLを使用したルーティング制御、および中型タイムスケールのMPLSおよびSRを使用したパス計画とパス制御。短いタイムスケールのトラフィック管理メカニズム。
* Capacity planning is an important component of how a service provider plans an effective IP network. These plans may take the following aspects into account: location of any new links or nodes, WECMP algorithms, existing and predicted traffic patterns, costs, link capacity, topology, routing design, and survivability.
* 容量計画は、サービスプロバイダーが効果的なIPネットワークを計画する方法の重要な要素です。これらの計画は、新しいリンクまたはノードの場所、WECMPアルゴリズム、既存および予測されたトラフィックパターン、コスト、リンク容量、トポロジ、ルーティング設計、および生存可能性を考慮に入れることができます。
* 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 analyzed and used to trigger TE mechanisms. Tools that perform what-if analysis can also be used to assist the TE process by reviewing scenarios before a new set of configurations are implemented in the operational network.
* 通常、運用ネットワークのパフォーマンスの最適化は、トラフィック統計、パフォーマンスパラメーター、および障害インジケーターがネットワークから継続的に収集される継続的なプロセスです。この経験的データは分析され、TEメカニズムをトリガーするために使用されます。What-IF分析を実行するツールは、運用ネットワークに新しい構成セットが実装される前にシナリオをレビューすることにより、TEプロセスを支援するために使用することもできます。
* Real-time intra-domain TE using the IGP is done by increasing the OSPF or IS-IS metric of a congested link until enough traffic has been diverted away from that link. This approach has some limitations as discussed in Section 6.2. Intra-domain TE approaches [RR94] [FT00] [FT01] [WANG] take traffic matrix, network topology, and network performance objectives as input and produce link metrics and load-sharing ratios. These processes open the possibility for intra-domain TE with IGP to be done in a more systematic way.
* IGPを使用したリアルタイムのドメインTEは、そのリンクから十分なトラフィックが迂回されるまで、混雑したリンクのOSPFまたはIS-I-Iメトリックを増やすことにより行われます。このアプローチには、セクション6.2で説明したようにいくつかの制限があります。ドメイン内TEアプローチ[RR94] [FT00] [FT01] [Wang]トラフィックマトリックス、ネットワークトポロジ、ネットワークパフォーマンス目標を入力として、リンクメトリックと負荷共有比を生成します。これらのプロセスは、より体系的な方法でIGPを使用してドメイン内TEの可能性を開きます。
Administrators of MPLS-TE networks specify and configure link attributes and resource constraints such as maximum reservable bandwidth and resource class attributes for the links in the domain. A link-state IGP that supports TE extensions (IS-IS-TE or OSPF-TE) is used to propagate information about network topology and link attributes to all routers in the domain. Network administrators specify the LSPs that are to originate at each router. For each LSP, the network administrator specifies the destination node and the attributes of the LSP that indicate the requirements that are to be satisfied during the path selection process. The attributes may include an explicit path for the LSP to follow, or the originating router may use a local constraint-based routing process to compute the path of the LSP. RSVP-TE is used as a signaling protocol to instantiate the LSPs. By assigning proper bandwidth values to links and LSPs, congestion caused by uneven traffic distribution can be avoided or mitigated.
MPLS-TEネットワークの管理者は、ドメイン内のリンクの最大予約可能帯域幅やリソースクラス属性などのリンク属性とリソース制約を指定および構成します。TE拡張機能（IS-IS-TEまたはOSPF-TE）をサポートするリンク状態IGPを使用して、ネットワークトポロジに関する情報を伝播し、ドメイン内のすべてのルーターにリンク属性を伝播します。ネットワーク管理者は、各ルーターで発生するLSPを指定します。各LSPについて、ネットワーク管理者は、パス選択プロセス中に満たされる要件を示す宛先ノードとLSPの属性を指定します。属性には、LSPが従うための明示的なパスが含まれる場合があります。または、発信元のルーターは、ローカル制約ベースのルーティングプロセスを使用してLSPのパスを計算する場合があります。RSVP-TEは、LSPをインスタンス化するためのシグナル伝達プロトコルとして使用されます。リンクとLSPに適切な帯域幅の値を割り当てることにより、不均一な交通量の分布によって引き起こされる輻輳を回避または軽減することができます。
The bandwidth attributes of an LSP relate to the bandwidth requirements of traffic that flows through the LSP. The traffic attribute of an LSP can be modified to accommodate persistent shifts in demand (traffic growth or reduction). If network congestion occurs due to unexpected events, existing LSPs can be rerouted to alleviate the situation, or the 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. A traffic matrix in an MPLS domain 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.
LSPの帯域幅属性は、LSPを介して流れるトラフィックの帯域幅要件に関連しています。LSPのトラフィック属性を変更して、需要の持続的なシフト（トラフィックの成長または削減）に対応することができます。予期しないイベントのためにネットワークの輻輳が発生した場合、既存のLSPを再ルーティングして状況を軽減するか、ネットワーク管理者が新しいLSPを構成して、トラフィックを代替パスに迂回させることができます。混雑したリンクの予約可能な帯域幅を削減して、一部のLSPを他のパスに再ルーティングするように強制することもできます。MPLSドメインのトラフィックマトリックスは、LSPのトラフィックを監視することで推定することもできます。このようなトラフィック統計は、ネットワーク計画やネットワークの最適化など、さまざまな目的に使用できます。
Network management and planning systems have evolved and assumed a lot of the responsibility for determining traffic paths in TE networks. This allows a network-wide view of resources and facilitates coordination of the use of resources for all traffic flows in the network. Initial solutions using a PCE to perform path computation on behalf of network routers have given way to an approach that follows the SDN architecture. A stateful PCE is able to track all of the LSPs in the network and can redistribute them to make better use of the available resources. Such a PCE can form part of a network orchestrator that uses PCEP or some other configuration and management interface to instruct the signaling protocol or directly program the routers.
ネットワーク管理および計画システムは進化し、TEネットワークのトラフィックパスを決定する多くの責任を引き受けました。これにより、リソースのネットワーク全体のビューが可能になり、ネットワーク内のすべてのトラフィックフローのリソースの使用の調整が促進されます。PCEを使用してネットワークルーターに代わってパス計算を実行する初期ソリューションは、SDNアーキテクチャに続くアプローチに取って代わりました。ステートフルPCEは、ネットワーク内のすべてのLSPを追跡することができ、利用可能なリソースをより適切に使用するためにそれらを再配布できます。このようなPCEは、PCEPまたは他の構成および管理インターフェイスを使用するネットワークオーケストレーターの一部を形成して、シグナリングプロトコルに指示するか、ルーターを直接プログラムできます。
SR leverages a centralized TE controller and either an MPLS or IPv6 forwarding plane but does not need to use a signaling protocol or management plane protocol to reserve resources in the routers. All resource reservation is logical within the controller and is not distributed to the routers. Packets are steered through the network using SR, and this may have configuration and operational scaling benefits.
SRは、集中化されたTEコントローラーとMPLSまたはIPv6転送面のいずれかをレバレッジしますが、シグナリングプロトコルまたは管理プレーンプロトコルを使用してルーターのリソースを予約する必要はありません。すべてのリソース予約はコントローラー内で論理的であり、ルーターに分布していません。パケットはSRを使用してネットワークを介して操縦され、これには構成と運用上のスケーリングの利点がある場合があります。
As mentioned in Section 7, there is usually no direct control over the distribution of inbound traffic to a domain. Therefore, the main goal of inter-domain TE is to optimize the distribution of outbound traffic between multiple inter-domain links. When operating a geographically widespread network (such as for a multi-national or global network provider), maintaining the ability to operate the network in a regional fashion where desired, while continuing to take advantage of the benefits of a globally interconnected network, also becomes an important objective.
セクション7で述べたように、通常、ドメインへのインバウンドトラフィックの分布を直接制御することはありません。したがって、ドメイン間TEの主な目標は、複数のドメイン間リンク間のアウトバウンドトラフィックの分布を最適化することです。地理的に広範囲にわたるネットワーク（多国籍またはグローバルネットワークプロバイダーなど）を操作する場合、グローバルに相互接続されたネットワークの利点を利用し続けながら、必要に応じて地域の方法でネットワークを運用する機能を維持する場合、重要な目的。
Inter-domain TE with BGP begins with the placement of multiple peering interconnection points that are in close proximity to traffic sources/destinations and offer lowest-cost paths across the network between the peering points and the sources/destinations. Some location-decision problems that arise in association with inter-domain routing are discussed in [AWD5].
BGPのドメイン間TEは、交通源/目的地に近接している複数のピアリング相互接続ポイントの配置から始まり、ピアリングポイントとソース/目的地の間のネットワーク全体で最も低コストのパスを提供します。ドメイン間ルーティングに関連して発生するいくつかの位置決定の問題は、[AWD5]で説明されています。
Once the locations of the peering interconnects have been determined and implemented, the network operator decides how best to handle the routes advertised by the peer, as well as how to propagate the peer's routes within their network. One way to engineer outbound traffic flows in a network with many peering interconnects is to create a hierarchy of peers. Generally, the shortest AS paths will be chosen to forward traffic, but BGP metrics can be used to prefer some peers and so favor particular paths. Preferred peers are those peers attached through peering interconnects with the most available capacity. Changes may be needed, for example, to deal 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 peer may be given a reduced preference. 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.
ピアリング相互接続の場所が決定および実装されたら、ネットワークオペレーターは、ピアによって宣伝されているルートをどのように処理するか、ネットワーク内のピアのルートを伝播する方法を決定します。多くのピアリング相互接続を備えたネットワーク内のアウトバウンドトラフィックフローを設計する1つの方法は、ピアの階層を作成することです。一般に、最も短いパスはトラフィックを転送するために選択されますが、BGPメトリックを使用して一部のピアを好むため、特定のパスを好むことができます。優先ピアは、最も利用可能な容量を持つピアリング相互接続を通じて添付されているピアです。たとえば、アップグレードで作業するのが難しい、またはネットワークへの接続のために高い価格を請求している「問題のピア」に対処するために変更が必要になる場合があります。その場合、ピアには優先度が低下する場合があります。このタイプの変更は、大量のトラフィックに影響を与える可能性があり、他の方法が望ましい結果を提供できなかった後にのみ使用されます。
When there are multiple exit points toward 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 connection. This can be achieved by using passive IGP metrics, AS_PATH filtering, or prefix filtering.
特定のピアに向かって複数の出口ポイントがあり、そのうちの1つだけが混雑している場合、トラフィックを完全にピアから遠ざける必要はありませんが、1つの混雑した接続からのみトラフィックを移す必要はありません。これは、パッシブIGPメトリック、AS_Pathフィルタリング、またはプレフィックスフィルタリングを使用することで実現できます。
In general, TE mechanisms are security neutral, and this document does not introduce new security issues.
一般に、TEメカニズムはセキュリティ中立であり、このドキュメントでは新しいセキュリティの問題は導入されていません。
Network security is, of course, an important issue, and TE mechanisms can have benefits and drawbacks:
もちろん、ネットワークセキュリティは重要な問題であり、TEメカニズムには利点と欠点があります。
* TE may use tunnels that can slightly help protect traffic from inspection and that, in some cases, can be secured using encryption.
* TEは、検査からトラフィックをわずかに保護するのにわずかに役立つトンネルを使用する場合があり、場合によっては暗号化を使用して保護できます。
* TE puts traffic onto predictable paths within the network that may make it easier to find and attack.
* TEは、トラフィックをネットワーク内の予測可能なパスに配置し、見つけやすくなり攻撃しやすくなります。
* TE often increases the complexity of operation and management of the network, which may lead to errors that compromise security.
* 多くの場合、ネットワークの操作と管理の複雑さを高め、セキュリティを損なうエラーにつながる可能性があります。
* TE enables traffic to be steered onto more secure links or to more secure parts of the network.
* TEにより、トラフィックをより安全なリンクまたはネットワークのより安全な部分に操縦することができます。
* TE can be used to steer traffic through network nodes that are able to provide additional security functions.
* TEを使用して、追加のセキュリティ関数を提供できるネットワークノードを介してトラフィックを操作できます。
The consequences of attacks on the control and management protocols used to operate TE networks can be significant:
TEネットワークの運用に使用される制御および管理プロトコルに対する攻撃の結果は、重要な場合があります。
* Traffic can be hijacked to pass through specific nodes that perform inspection or even to be delivered to the wrong place.
* トラフィックをハイジャックして、検査を実行したり、間違った場所に配信される特定のノードを通過できます。
* Traffic can be steered onto paths that deliver quality that is below the desired quality.
* トラフィックは、目的の品質を下回る品質を提供するパスに操縦できます。
* Networks can be congested or have resources on key links consumed.
* ネットワークを混雑させることも、キーリンクのリソースを消費することもできます。
Thus, it is important to use adequate protection mechanisms, such as authentication, on all protocols used to deliver TE.
したがって、TEを提供するために使用されるすべてのプロトコルで、認証などの適切な保護メカニズムを使用することが重要です。
Certain aspects of a network may be deduced from the details of the TE paths that are used. For example, the link connectivity of the network and the quality and load on individual links may be inferred from knowing the paths of traffic and the requirements they place on the network (for example, by seeing the control messages or through path-trace techniques). Such knowledge can be used to launch targeted attacks (for example, taking down critical links) or can reveal commercially sensitive information (for example, whether a network is close to capacity). Therefore, network operators may choose techniques that mask or hide information from within the network.
ネットワークの特定の側面は、使用されているTEパスの詳細から推測される場合があります。たとえば、ネットワークのリンク接続と個々のリンクの品質と負荷は、トラフィックのパスとネットワーク上に配置する要件を知ることから推測される場合があります（たとえば、コントロールメッセージまたはパストレーステクニックを介して）。このような知識は、標的攻撃を開始するために使用できます（たとえば、重要なリンクを削除する）、または商業的に機密情報を明らかにすることができます（たとえば、ネットワークが容量に近いかどうか）。したがって、ネットワークオペレーターは、ネットワーク内から情報をマスクまたは非表示にする手法を選択できます。
External control interfaces that are introduced to provide additional control and management of TE systems (see Section 5.1.2) provide flexibility to management and to customers, but they do so at the risk of exposing the internals of a network to potentially malicious actors. The protocols used at these interfaces must be secured to protect against snooping and modification, and use of the interfaces must be authenticated.
TEシステムの追加の制御と管理を提供するために導入された外部制御インターフェイス（セクション5.1.2を参照）は、管理と顧客に柔軟性を提供しますが、ネットワークの内部を潜在的に悪意のあるアクターに暴露するリスクがあります。これらのインターフェイスで使用されるプロトコルは、スヌーピングと変更から保護するために保護する必要があり、インターフェイスの使用を認証する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[AFD03] Pan, R., Breslau, L., Prabhakar, B., and S. Shenker,
"Approximate fairness through differential dropping", ACM
SIGCOMM Computer Communication Review, Volume 33, Issue 2,
Pages 23-39, DOI 10.1145/956981.956985, April 2003,
<https://dl.acm.org/doi/10.1145/956981.956985>.
[AJ19] Adekitan, A., Abolade, J., and O. Shobayo, "Data mining
approach for predicting the daily Internet data traffic of
a smart university", Journal of Big Data, Volume 6, Number
1, Page 1, DOI 10.1186/s40537-019-0176-5, February 2019,
<https://journalofbigdata.springeropen.com/track/
pdf/10.1186/s40537-019-0176-5.pdf>.
[ATSSS] 3GPP, "Study on access traffic steering, switch and
splitting support in the 5G System (5GS) architecture",
Release 16, 3GPP TR 23.793, December 2018,
<https://www.3gpp.org/ftp//Specs/
archive/23_series/23.793/23793-g00.zip>.
[AWD2] Awduche, D., "MPLS and traffic engineering in IP
networks", IEEE Communications Magazine, Volume 37, Issue
12, Pages 42-47, DOI 10.1109/35.809383, December 1999,
<https://ieeexplore.ieee.org/document/809383>.
[AWD5] Awduche, D., "An approach to optimal peering between
autonomous systems in the Internet", Proceedings 7th
International Conference on Computer Communications and
Networks (Cat. No. 98EX226),
DOI 10.1109/ICCCN.1998.998795, October 1998,
<https://ieeexplore.ieee.org/document/998795>.
[E.360.1] ITU-T, "Framework for QoS routing and related traffic
engineering methods for IP-, ATM-, and TDM-based
multiservice networks", ITU-T Recommendation E.360.1, May
2002, <https://www.itu.int/rec/T-REC-E.360.1-200205-I/en>.
[ENHANCED-VPN]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for NRP-based Enhanced Virtual Private Network",
Work in Progress, Internet-Draft, draft-ietf-teas-
enhanced-vpn-17, 25 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-17>.
[Err309] RFC Errata, Erratum ID 309, RFC 3272,
<https://www.rfc-editor.org/errata/eid309>.
[EVPN-UNEQUAL-LB]
Malhotra, N., Ed., Sajassi, A., Rabadan, J., Drake, J.,
Lingala, A., and S. Thoria, "Weighted Multi-Path
Procedures for EVPN Multi-Homing", Work in Progress,
Internet-Draft, draft-ietf-bess-evpn-unequal-lb-21, 7
December 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bess-evpn-unequal-lb-21>.
[FLJA93] Floyd, S. and V. Jacobson, "Random Early Detection
Gateways for Congestion Avoidance", IEEE/ACM Transactions
on Networking, Volume 1, Issue 4, Pages 397-413,
DOI 10.1109/90.251892, August 1993,
<https://www.icir.org/floyd/papers/early.twocolumn.pdf>.
[FT00] Fortz, B. and M. Thorup, "Internet Traffic Engineering by
Optimizing OSPF Weights", Proceedings IEEE INFOCOM 2000,
DOI 10.1109/INFCOM.2000.832225, March 2000,
<https://www.cs.cornell.edu/courses/cs619/2004fa/
documents/ospf_opt.pdf>.
[FT01] Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in
a Changing World", IEEE Journal on Selected Areas in
Communications, DOI 10.1109/JSAC.2002.1003042, May 2002,
<https://ieeexplore.ieee.org/document/1003042>.
[GRPC] gRPC Authors, "gRPC: A high performance, open source
universal RPC framework", <https://grpc.io>.
[KELLY] Kelly, F., "Notes on effective bandwidths", Oxford
University Press, 1996.
[MA] Ma, Q., "Quality-of-Service Routing in Integrated Services
Networks", Ph.D. Dissertation, Carnegie Mellon University,
CMU-CS-98-138, January 1998,
<https://apps.dtic.mil/sti/pdfs/ADA352299.pdf>.
[MATE] Elwalid, A., Jin, C., Low, S., and I. Widjaja, "MATE: MPLS
Adaptive Traffic Engineering", Proceedings IEEE INFOCOM
2001, Conference on Computer Communications, Twentieth
Annual Joint Conference of the IEEE Computer and
Communications Society (Cat. No. 01CH37213),
DOI 10.1109/INFCOM.2001.916625, August 2002,
<https://www.yumpu.com/en/document/view/35140398/mate-
mpls-adaptive-traffic-engineering-infocom-ieee-xplore/8>.
[MR99] Mitra, D. and K.G. Ramakrishnan, "A case study of
multiservice, multipriority traffic engineering design for
data networks", Seamless Interconnection for Universal
Services, Global Telecommunications Conference,
GLOBECOM'99, (Cat. No. 99CH37042),
DOI 10.1109/GLOCOM.1999.830281, December 1999,
<https://ieeexplore.ieee.org/document/830281>.
[MULTIPATH-DCCP]
Amend, M., Ed., Brunstrom, A., Kassler, A., Rakocevic, V.,
and S. Johnson, "DCCP Extensions for Multipath Operation
with Multiple Addresses", Work in Progress, Internet-
Draft, draft-ietf-tsvwg-multipath-dccp-11, 12 October
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
tsvwg-multipath-dccp-11>.
[NETWORK-SLICES]
Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L. M., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", Work in Progress, Internet-Draft, draft-
ietf-teas-ietf-network-slices-25, 14 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slices-25>.
[PERFORMANCE-ROUTING]
Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C.
Jacquenet, "Performance-based BGP Routing Mechanism", Work
in Progress, Internet-Draft, draft-ietf-idr-performance-
routing-03, 22 December 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
performance-routing-03>.
[QUIC-MULTIPATH]
Liu, Y., Ed., Ma, Y., Ed., De Coninck, Q., Ed.,
Bonaventure, O., Huitema, C., and M. Kühlewind, Ed.,
"Multipath Extension for QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-multipath-06, 23 October
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
quic-multipath-06>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1102] Clark, D., "Policy routing in Internet protocols",
RFC 1102, DOI 10.17487/RFC1102, May 1989,
<https://www.rfc-editor.org/info/rfc1102>.
[RFC1104] Braun, H., "Models of policy based routing", RFC 1104,
DOI 10.17487/RFC1104, June 1989,
<https://www.rfc-editor.org/info/rfc1104>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>.
[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A
Framework for QoS-based Routing in the Internet",
RFC 2386, DOI 10.17487/RFC2386, August 1998,
<https://www.rfc-editor.org/info/rfc2386>.
[RFC2474] 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,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, DOI 10.17487/RFC2678, September
1999, <https://www.rfc-editor.org/info/rfc2678>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<https://www.rfc-editor.org/info/rfc2702>.
[RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722,
DOI 10.17487/RFC2722, October 1999,
<https://www.rfc-editor.org/info/rfc2722>.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753,
DOI 10.17487/RFC2753, January 2000,
<https://www.rfc-editor.org/info/rfc2753>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<https://www.rfc-editor.org/info/rfc2961>.
[RFC2998] 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, DOI 10.17487/RFC2998,
November 2000, <https://www.rfc-editor.org/info/rfc2998>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, DOI 10.17487/RFC3086,
April 2001, <https://www.rfc-editor.org/info/rfc3086>.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, DOI 10.17487/RFC3124, June 2001,
<https://www.rfc-editor.org/info/rfc3124>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, DOI 10.17487/RFC3175, September 2001,
<https://www.rfc-editor.org/info/rfc3175>.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198, November
2001, <https://www.rfc-editor.org/info/rfc3198>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3270] Le Faucheur, F., Ed., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, DOI 10.17487/RFC3270,
May 2002, <https://www.rfc-editor.org/info/rfc3270>.
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
<https://www.rfc-editor.org/info/rfc3272>.
[RFC3469] Sharma, V., Ed. and F. Hellstrand, Ed., "Framework for
Multi-Protocol Label Switching (MPLS)-based Recovery",
RFC 3469, DOI 10.17487/RFC3469, February 2003,
<https://www.rfc-editor.org/info/rfc3469>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<https://www.rfc-editor.org/info/rfc3945>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
DOI 10.17487/RFC4124, June 2005,
<https://www.rfc-editor.org/info/rfc4124>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
<https://www.rfc-editor.org/info/rfc4461>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 5151, DOI 10.17487/RFC5151, February
2008, <https://www.rfc-editor.org/info/rfc5151>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <https://www.rfc-editor.org/info/rfc5250>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
DOI 10.17487/RFC5394, December 2008,
<https://www.rfc-editor.org/info/rfc5394>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
DOI 10.17487/RFC5470, March 2009,
<https://www.rfc-editor.org/info/rfc5470>.
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
Flow Information Export (IPFIX) Applicability", RFC 5472,
DOI 10.17487/RFC5472, March 2009,
<https://www.rfc-editor.org/info/rfc5472>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
July 2009, <https://www.rfc-editor.org/info/rfc5557>.
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009,
<https://www.rfc-editor.org/info/rfc5559>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based
Parallel NFS (pNFS) Operations", RFC 5664,
DOI 10.17487/RFC5664, January 2010,
<https://www.rfc-editor.org/info/rfc5664>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009,
<https://www.rfc-editor.org/info/rfc5671>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009,
<https://www.rfc-editor.org/info/rfc5693>.
[RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths",
RFC 6107, DOI 10.17487/RFC6107, February 2011,
<https://www.rfc-editor.org/info/rfc6107>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<https://www.rfc-editor.org/info/rfc6372>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[RFC6601] Ash, G., Ed. and D. McDysan, "Generic Connection Admission
Control (GCAC) Algorithm Specification for IP/MPLS
Networks", RFC 6601, DOI 10.17487/RFC6601, April 2012,
<https://www.rfc-editor.org/info/rfc6601>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
for Subscription to YANG Datastores", RFC 7923,
DOI 10.17487/RFC7923, June 2016,
<https://www.rfc-editor.org/info/rfc7923>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.
[RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based
on Proportional Integral Controller Enhanced (PIE) for
Data-Over-Cable Service Interface Specifications (DOCSIS)
Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February
2017, <https://www.rfc-editor.org/info/rfc8034>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
Application-Layer Traffic Optimization (ALTO)", RFC 8189,
DOI 10.17487/RFC8189, October 2017,
<https://www.rfc-editor.org/info/rfc8189>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S.,
Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol",
RFC 8803, DOI 10.17487/RFC8803, July 2020,
<https://www.rfc-editor.org/info/rfc8803>.
[RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N.
Schwan, "Application-Layer Traffic Optimization (ALTO)
Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November
2020, <https://www.rfc-editor.org/info/rfc8896>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
"Deterministic Networking (DetNet) Data Plane: IP over
IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023,
DOI 10.17487/RFC9023, June 2021,
<https://www.rfc-editor.org/info/rfc9023>.
[RFC9040] Touch, J., Welzl, M., and S. Islam, "TCP Control Block
Interdependence", RFC 9040, DOI 10.17487/RFC9040, July
2021, <https://www.rfc-editor.org/info/rfc9040>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>.
[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>.
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, <https://www.rfc-editor.org/info/rfc9315>.
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-
Queue Coupled Active Queue Management (AQM) for Low
Latency, Low Loss, and Scalable Throughput (L4S)",
RFC 9332, DOI 10.17487/RFC9332, January 2023,
<https://www.rfc-editor.org/info/rfc9332>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9439] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and
L. Contreras, "Application-Layer Traffic Optimization
(ALTO) Performance Cost Metrics", RFC 9439,
DOI 10.17487/RFC9439, August 2023,
<https://www.rfc-editor.org/info/rfc9439>.
[RFC9502] Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica,
R., and P. Psenak, "IGP Flexible Algorithm in IP
Networks", RFC 9502, DOI 10.17487/RFC9502, November 2023,
<https://www.rfc-editor.org/info/rfc9502>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RR94] Rodrigues, M. and K.G. Ramakrishnan, "Optimal routing in
shortest-path data networks", Bell Labs Technical Journal,
Volume 6, Issue 1, Pages 117-138, DOI 10.1002/bltj.2267,
August 2002,
<https://onlinelibrary.wiley.com/doi/abs/10.1002/
bltj.2267>.
[SLDC98] Suter, B., Lakshman, T.V., Stiliadis, D., and A.K.
Choudhury, "Design considerations for supporting TCP with
per-flow queueing", Proceedings IEEE INFOCOM '98,
DOI 10.1109/INFCOM.1998.659666, April 1998,
<https://ieeexplore.ieee.org/document/659666>.
[SR-TE-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in
BGP", Work in Progress, Internet-Draft, draft-ietf-idr-
segment-routing-te-policy-26, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-26>.
[SR-TI-LFA]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
13, 16 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-13>.
[TE-QoS-ROUTING]
Ash, G., "Traffic Engineering & QoS Methods for IP-, ATM-,
& Based Multiservice Networks", Work in Progress,
Internet-Draft, draft-ietf-tewg-qos-routing-04, October
2001, <https://datatracker.ietf.org/doc/html/draft-ietf-
tewg-qos-routing-04>.
[WANG] Wang, Y., Wang, Z., and L. Zhang, "Internet traffic
engineering without full mesh overlaying", Proceedings
IEEE INFOCOM 2001, DOI 10.1109/INFCOM.2001.916782, April
2001, <https://ieeexplore.ieee.org/document/916782>.
[XIAO] Xiao, X., Hannan, A., Bailey, B., and L. Ni, "Traffic
Engineering with MPLS in the Internet", IEEE Network,
Volume 14, Issue 2, Pages 28-33, DOI 10.1109/65.826369,
March 2000,
<https://courses.cs.washington.edu/courses/cse561/02au/
papers/xiao-mpls-net00.pdf>.
[YARE95] Yang, C. and A. Reddy, "A Taxonomy for Congestion Control
Algorithms in Packet Switching Networks", IEEE Network,
Pages 34-45, DOI 10.1109/65.397042, August 1995,
<https://ieeexplore.ieee.org/document/397042>.
The changes to this document since [RFC3272] are substantial and not easily summarized as section-by-section changes. The material in the document has been moved around considerably, some of it removed, and new text added.
[RFC3272]以降のこのドキュメントの変更は、かなりのものであり、セクションごとの変更として簡単に要約されません。ドキュメント内の資料はかなり移動され、その一部は削除され、新しいテキストが追加されました。
The approach taken here is to list the contents of both [RFC3272] and this document saying, respectively, where the text has been placed and where the text came from.
ここで採用されているアプローチは、[RFC3272]とこの文書の両方の内容を、それぞれテキストが配置された場所とテキストがどこから来たのかをリストすることです。
* Section 1.0 ("Introduction"): Edited in place in Section 1.
* セクション1.0（「はじめに」）：セクション1で編集されています。
- Section 1.1 ("What is Internet Traffic Engineering?"): Edited in place in Section 1.1.
- セクション1.1（「インターネットトラフィックエンジニアリングとは？」）：セクション1.1で編集されています。
- Section 1.2 ("Scope"): Moved to Section 1.3.
- セクション1.2（「スコープ」）：セクション1.3に移動しました。
- Section 1.3 ("Terminology"): Moved to Section 1.4 with some obsolete terms removed and a little editing.
- セクション1.3（「用語」）：いくつかの時代遅れの用語が削除され、少し編集されて、セクション1.4に移動しました。
* Section 2.0 ("Background"): Retained as Section 2 with some text removed.
* セクション2.0（ "背景"）：セクション2として保持され、テキストが削除されました。
- Section 2.1 ("Context of Internet Traffic Engineering"): Retained as Section 2.1.
- セクション2.1（「インターネットトラフィックエンジニアリングのコンテキスト」）：セクション2.1として保持されます。
- Section 2.2 ("Network Context"): Rewritten as Section 2.2.
- セクション2.2（「ネットワークコンテキスト」）：セクション2.2として書き直されました。
- Section 2.3 ("Problem Context"): Rewritten as Section 2.3.
- セクション2.3（「問題のコンテキスト」）：セクション2.3として書き直されました。
o Section 2.3.1 ("Congestion and its Ramifications"): Retained as Section 2.3.1.
o セクション2.3.1（「混雑とその影響」）：セクション2.3.1として保持。
- Section 2.4 ("Solution Context"): Edited as Section 2.4.
- セクション2.4（「ソリューションコンテキスト」）：セクション2.4として編集。
o Section 2.4.1 ("Combating the Congestion Problem"): Reformatted as Section 2.4.1.
o セクション2.4.1（「混雑問題の闘い」）：セクション2.4.1として再フォーマット。
- Section 2.5 ("Implementation and Operational Context"): Retained as Section 2.5.
- セクション2.5（「実装と運用コンテキスト」）：セクション2.5として保持されます。
* Section 3.0 ("Traffic Engineering Process Model"): Retained as Section 3.
* セクション3.0（「トラフィックエンジニアリングプロセスモデル」）：セクション3として保持されます。
- Section 3.1 ("Components of the Traffic Engineering Process Model"): Retained as Section 3.1.
- セクション3.1（「トラフィックエンジニアリングプロセスモデルのコンポーネント」）：セクション3.1として保持されます。
- Section 3.2 ("Measurement"): Merged into Section 3.1.
- セクション3.2（「測定」）：セクション3.1に統合。
- Section 3.3 ("Modeling, Analysis, and Simulation"): Merged into Section 3.1.
- セクション3.3（「モデリング、分析、およびシミュレーション」）：セクション3.1に統合。
- Section 3.4 ("Optimization"): Merged into Section 3.1.
- セクション3.4（「最適化」）：セクション3.1にマージされました。
* Section 4.0 ("Historical Review and Recent Developments"): Retained as Section 5, but the very historic aspects have been deleted.
* セクション4.0（「歴史的レビューと最近の開発」）：セクション5として保持されていますが、非常に歴史的な側面は削除されています。
- Section 4.1 ("Traffic Engineering in Classical Telephone Networks"): Deleted.
- セクション4.1（「古典的な電話ネットワークのトラフィックエンジニアリング」）：削除。
- Section 4.2 ("Evolution of Traffic Engineering in the Internet"): Deleted.
- セクション4.2（「インターネットでの交通工学の進化」）：削除。
- Section 4.3 ("Overlay Model"): Deleted.
- セクション4.3（「オーバーレイモデル」）：削除。
- Section 4.4 ("Constraint-Based Routing"): Retained as Section 5.1.3.1, but moved into Section 5.1.
- セクション4.4（「制約ベースのルーティング」）：セクション5.1.3.1として保持されますが、セクション5.1に移動しました。
- Section 4.5 ("Overview of Other IETF Projects Related to Traffic Engineering"): Retained as Section 5.1 with many new subsections.
- セクション4.5（「トラフィックエンジニアリングに関連する他のIETFプロジェクトの概要」）：多くの新しいサブセクションでセクション5.1として保持されます。
o Section 4.5.1 ("Integrated Services"): Retained as Section 5.1.1.1.
o セクション4.5.1（「統合サービス」）：セクション5.1.1.1として保持されます。
o Section 4.5.2 ("RSVP"): Retained as Section 5.1.3.2 with some edits.
o セクション4.5.2（ "RSVP"）：いくつかの編集でセクション5.1.3.2として保持されます。
o Section 4.5.3 ("Differentiated Services"): Retained as Section 5.1.1.2.
o セクション4.5.3（「差別化されたサービス」）：セクション5.1.1.2として保持されます。
o Section 4.5.4 ("MPLS"): Retained as Section 5.1.3.3.
o セクション4.5.4（ "MPLS"）：セクション5.1.3.3として保持されます。
o Section 4.5.5 ("IP Performance Metrics"): Retained as Section 5.1.3.6.
o セクション4.5.5（「IPパフォーマンスメトリック」）：セクション5.1.3.6として保持されます。
o Section 4.5.6 ("Flow Measurement"): Retained as Section 5.1.3.7 with some reformatting.
o セクション4.5.6（ "フロー測定"）：セクション5.1.3.7として保持され、何らかの再フォーマット。
o Section 4.5.7 ("Endpoint Congestion Management"): Retained as Section 5.1.3.8.
o セクション4.5.7（ "エンドポイント混雑管理"）：セクション5.1.3.8として保持されます。
- Section 4.6 ("Overview of ITU Activities Related to Traffic Engineering"): Deleted.
- セクション4.6（「トラフィックエンジニアリングに関連するITUアクティビティの概要」）：削除。
- Section 4.7 ("Content Distribution"): Retained as Section 5.2.
- セクション4.7（「コンテンツ分布」）：セクション5.2として保持されます。
* Section 5.0 ("Taxonomy of Traffic Engineering Systems"): Retained as Section 4.
* セクション5.0（「トラフィックエンジニアリングシステムの分類法」）：セクション4として保持されます。
- Section 5.1 ("Time-Dependent Versus State-Dependent"): Retained as Section 4.1.
- セクション5.1（ "時間依存性と状態依存性"）：セクション4.1として保持されます。
- Section 5.2 ("Offline Versus Online"): Retained as Section 4.2.
- セクション5.2（「オフライン対オンライン」）：セクション4.2として保持されます。
- Section 5.3 ("Centralized Versus Distributed"): Retained as Section 4.3 with additions.
- セクション5.3（「集中化対分布」）：追加のセクション4.3として保持されます。
- Section 5.4 ("Local Versus Global"): Retained as Section 4.4.
- セクション5.4（「ローカル対グローバル」）：セクション4.4として保持されます。
- Section 5.5 ("Prescriptive Versus Descriptive"): Retained as Section 4.5 with additions.
- セクション5.5（「規範的と記述的」）：追加のセクション4.5として保持されます。
- Section 5.6 ("Open-Loop Versus Closed-Loop"): Retained as Section 4.6.
- セクション5.6（「オープンループ対閉ループ」）：セクション4.6として保持されます。
- Section 5.7 ("Tactical vs Strategic"): Retained as Section 4.7.
- セクション5.7（「戦術と戦略的」）：セクション4.7として保持。
* Section 6.0 ("Recommendations for Internet Traffic Engineering"): Retained as Section 6.
* セクション6.0（「インターネットトラフィックエンジニアリングに関する推奨事項」）：セクション6として保持されます。
- Section 6.1 ("Generic Non-functional Recommendations"): Retained as Section 6.1.
- セクション6.1（「一般的な非機能的推奨事項」）：セクション6.1として保持されます。
- Section 6.2 ("Routing Recommendations"): Retained as Section 6.2 with edits.
- セクション6.2（「ルーティングの推奨事項」）：編集を備えたセクション6.2として保持されます。
- Section 6.3 ("Traffic Mapping Recommendations"): Retained as Section 6.3.
- セクション6.3（「トラフィックマッピングの推奨事項」）：セクション6.3として保持されます。
- Section 6.4 ("Measurement Recommendations"): Retained as Section 6.4.
- セクション6.4（「測定の推奨事項」）：セクション6.4として保持されます。
- Section 6.5 ("Network Survivability"): Retained as Section 6.6.
- セクション6.5（「ネットワークの生存性」）：セクション6.6として保持されます。
o Section 6.5.1 ("Survivability in MPLS Based Networks"): Retained as Section 6.6.1.
o セクション6.5.1（「MPLSベースのネットワークの生存可能性」）：セクション6.6.1として保持されます。
o Section 6.5.2 ("Protection Option"): Retained as Section 6.6.2.
o セクション6.5.2（「保護オプション」）：セクション6.6.2として保持されます。
- Section 6.6 ("Traffic Engineering in Diffserv Environments"): Retained as Section 6.8 with edits.
- セクション6.6（「diffserv環境におけるトラフィックエンジニアリング」）：編集を備えたセクション6.8として保持されます。
- Section 6.7 ("Network Controllability"): Retained as Section 6.9.
- セクション6.7（「ネットワーク制御可能性」）：セクション6.9として保持されます。
* Section 7.0 ("Inter-Domain Considerations"): Retained as Section 7.
* セクション7.0（「ドメイン間の考慮事項」）：セクション7として保持されます。
* Section 8.0 ("Overview of Contemporary TE Practices in Operational IP Networks"): Retained as Section 8.
* セクション8.0（「運用IPネットワークにおける現代のTEプラクティスの概要」：セクション8として保持されます。
* Section 9.0 ("Conclusion"): Removed.
* セクション9.0（「結論」）：削除。
* Section 10.0 ("Security Considerations"): Retained as Section 9 with considerable new text.
* セクション10.0（「セキュリティ上の考慮事項」）：かなりの新しいテキストでセクション9として保持されます。
* Section 1: Based on Section 1 of [RFC3272].
* セクション1：[RFC3272]のセクション1に基づいています。
- Section 1.1: Based on Section 1.1 of [RFC3272].
- セクション1.1：[RFC3272]のセクション1.1に基づいています。
- Section 1.2: New for this document.
- セクション1.2：このドキュメントの新しい。
- Section 1.3: Based on Section 1.2 of [RFC3272].
- セクション1.3：[RFC3272]のセクション1.2に基づいています。
- Section 1.4: Based on Section 1.3 of [RFC3272].
- セクション1.4：[RFC3272]のセクション1.3に基づいています。
* Section 2: Based on Section 2 of [RFC3272].
* セクション2：[RFC3272]のセクション2に基づいています。
- Section 2.1: Based on Section 2.1 of [RFC3272].
- セクション2.1：[RFC3272]のセクション2.1に基づいています。
- Section 2.2: Based on Section 2.2 of [RFC3272].
- セクション2.2：[RFC3272]のセクション2.2に基づいています。
- Section 2.3: Based on Section 2.3 of [RFC3272].
- セクション2.3：[RFC3272]のセクション2.3に基づいています。
o Section 2.3.1: Based on Section 2.3.1 of [RFC3272].
o セクション2.3.1：[RFC3272]のセクション2.3.1に基づいています。
- Section 2.4: Based on Section 2.4 of [RFC3272].
- セクション2.4：[RFC3272]のセクション2.4に基づいています。
o Section 2.4.1: Based on Section 2.4.1 of [RFC3272].
o セクション2.4.1：[RFC3272]のセクション2.4.1に基づいています。
- Section 2.5: Based on Section 2.5 of [RFC3272].
- セクション2.5：[RFC3272]のセクション2.5に基づいています。
* Section 3: Based on Section 3 of [RFC3272].
* セクション3：[RFC3272]のセクション3に基づいています。
- Section 3.1: Based on Sections 3.1, 3.2, 3.3, and 3.4 of [RFC3272].
- セクション3.1：[RFC3272]のセクション3.1、3.2、3.3、および3.4に基づいています。
* Section 4: Based on Section 5 of [RFC3272].
* セクション4：[RFC3272]のセクション5に基づいています。
- Section 4.1: Based on Section 5.1 of [RFC3272].
- セクション4.1：[RFC3272]のセクション5.1に基づいています。
- Section 4.2: Based on Section 5.2 of [RFC3272].
- セクション4.2：[RFC3272]のセクション5.2に基づいています。
- Section 4.3: Based on Section 5.3 of [RFC3272].
- セクション4.3：[RFC3272]のセクション5.3に基づいています。
o Section 4.3.1: New for this document.
o セクション4.3.1：このドキュメントの新しい。
o Section 4.3.2: New for this document.
o セクション4.3.2：このドキュメントの新しい。
- Section 4.4: Based on Section 5.4 of [RFC3272].
- セクション4.4：[RFC3272]のセクション5.4に基づいています。
- Section 4.5: Based on Section 5.5 of [RFC3272].
- セクション4.5：[RFC3272]のセクション5.5に基づいています。
o Section 4.5.1: New for this document.
o セクション4.5.1：このドキュメントの新しい。
- Section 4.6: Based on Section 5.6 of [RFC3272].
- セクション4.6：[RFC3272]のセクション5.6に基づいています。
- Section 4.7: Based on Section 5.7 of [RFC3272].
- セクション4.7：[RFC3272]のセクション5.7に基づいています。
* Section 5: Based on Section 4 of [RFC3272].
* セクション5：[RFC3272]のセクション4に基づいています。
- Section 5.1: Based on Section 4.5 of [RFC3272].
- セクション5.1：[RFC3272]のセクション4.5に基づいています。
o Section 5.1.1.1: Based on Section 4.5.1 of [RFC3272].
o セクション5.1.1.1：[RFC3272]のセクション4.5.1に基づいています。
o Section 5.1.1.2: Based on Section 4.5.3 of [RFC3272].
o セクション5.1.1.2：[RFC3272]のセクション4.5.3に基づいています。
o Section 5.1.1.3: New for this document.
o セクション5.1.1.3：このドキュメントの新しい。
o Section 5.1.1.4: New for this document.
o セクション5.1.1.4：このドキュメントの新しい。
o Section 5.1.1.5: New for this document.
o セクション5.1.1.5：このドキュメントの新しい。
o Section 5.1.2.1: New for this document.
o セクション5.1.2.1：このドキュメントの新規。
o Section 5.1.2.2: New for this document.
o セクション5.1.2.2：このドキュメントの新しい。
o Section 5.1.2.3: New for this document.
o セクション5.1.2.3：このドキュメントの新しい。
o Section 5.1.3.1: Based on Section 4.4 of [RFC3272].
o セクション5.1.3.1：[RFC3272]のセクション4.4に基づいています。
+ Section 5.1.3.1.1: New for this document.
+ セクション5.1.3.1.1：このドキュメントの新しい。
o Section 5.1.3.2: Based on Section 4.5.2 of [RFC3272].
o セクション5.1.3.2：[RFC3272]のセクション4.5.2に基づいています。
o Section 5.1.3.3: Based on Section 4.5.4 of [RFC3272].
o セクション5.1.3.3：[RFC3272]のセクション4.5.4に基づいています。
o Section 5.1.3.4: New for this document.
o セクション5.1.3.4：このドキュメントの新しい。
o Section 5.1.3.5: New for this document.
o セクション5.1.3.5：このドキュメントの新しい。
o Section 5.1.3.6: Based on Section 4.5.5 of [RFC3272].
o セクション5.1.3.6：[RFC3272]のセクション4.5.5に基づいています。
o Section 5.1.3.7: Based on Section 4.5.6 of [RFC3272].
o セクション5.1.3.7：[RFC3272]のセクション4.5.6に基づいています。
o Section 5.1.3.8: Based on Section 4.5.7 of [RFC3272].
o セクション5.1.3.8：[RFC3272]のセクション4.5.7に基づいています。
o Section 5.1.3.9: New for this document.
o セクション5.1.3.9：このドキュメントの新しい。
o Section 5.1.3.10: New for this document.
o セクション5.1.3.10：このドキュメントの新しい。
o Section 5.1.3.11: New for this document.
o セクション5.1.3.11：このドキュメントの新しい。
o Section 5.1.3.12: New for this document.
o セクション5.1.3.12：このドキュメントの新しい。
o Section 5.1.3.13: New for this document.
o セクション5.1.3.13：このドキュメントの新しい。
o Section 5.1.3.14: New for this document.
o セクション5.1.3.14：このドキュメントの新しい。
o Section 5.1.3.15: New for this document.
o セクション5.1.3.15：このドキュメントの新しい。
- Section 5.2: Based on Section 4.7 of [RFC3272].
- セクション5.2：[RFC3272]のセクション4.7に基づいています。
* Section 6: Based on Section 6 of [RFC3272].
* セクション6：[RFC3272]のセクション6に基づいています。
- Section 6.1: Based on Section 6.1 of [RFC3272].
- セクション6.1：[RFC3272]のセクション6.1に基づいています。
- Section 6.2: Based on Section 6.2 of [RFC3272].
- セクション6.2：[RFC3272]のセクション6.2に基づいています。
- Section 6.3: Based on Section 6.3 of [RFC3272].
- セクション6.3：[RFC3272]のセクション6.3に基づいています。
- Section 6.4: Based on Section 6.4 of [RFC3272].
- セクション6.4：[RFC3272]のセクション6.4に基づいています。
- Section 6.5: New for this document.
- セクション6.5：このドキュメントの新しい。
- Section 6.6: Based on Section 6.5 of [RFC3272].
- セクション6.6：[RFC3272]のセクション6.5に基づいています。
o Section 6.6.1: Based on Section 6.5.1 of [RFC3272].
o セクション6.6.1：[RFC3272]のセクション6.5.1に基づいています。
o Section 6.6.2: Based on Section 6.5.2 of [RFC3272].
o セクション6.6.2：[RFC3272]のセクション6.5.2に基づいています。
- Section 6.7: New for this document.
- セクション6.7：このドキュメントの新しい。
- Section 6.8: Based on Section 6.6 of [RFC3272].
- セクション6.8：[RFC3272]のセクション6.6に基づいています。
- Section 6.9: Based on Section 6.7 of [RFC3272].
- セクション6.9：[RFC3272]のセクション6.7に基づいています。
* Section 7: Based on Section 7 of [RFC3272].
* セクション7：[RFC3272]のセクション7に基づいています。
* Section 8: Based on Section 8 of [RFC3272].
* セクション8：[RFC3272]のセクション8に基づいています。
* Section 9: Based on Section 10 of [RFC3272].
* セクション9：[RFC3272]のセクション10に基づいています。
Much of the text in this document is derived from [RFC3272]. The editor and contributors to this document would like to express their gratitude to all involved in that work. Although the source text has been edited in the production of this document, the original authors should be considered as contributors to this work. They were:
このドキュメントのテキストの多くは、[RFC3272]から派生しています。このドキュメントの編集者と貢献者は、その作業に関与しているすべての人に感謝の意を表したいと考えています。ソーステキストはこのドキュメントの作成で編集されていますが、元の著者はこの作業への貢献者と見なされるべきです。彼らはいた：
Daniel O. Awduche
Movaz Networks
Angela Chiu
Celion Networks
Anwar Elwalid
Lucent Technologies
Indra Widjaja
Bell Labs, Lucent Technologies
XiPeng Xiao
Redback Networks
The acknowledgements in [RFC3272] were as below. All people who helped in the production of that document also need to be thanked for the carry-over into this new document.
[RFC3272]の謝辞は以下のとおりでした。その文書の作成を手伝ったすべての人々は、この新しいドキュメントへのキャリーオーバーに感謝する必要があります。
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にコメントとサポートに感謝したいと思います。
The early draft versions of this document were produced by the TEAS Working Group's RFC3272bis Design Team. The full list of members of this team is:
このドキュメントの初期ドラフトバージョンは、TeasワーキンググループのRFC3272BISデザインチームによって作成されました。このチームのメンバーの完全なリストは次のとおりです。
Acee Lindem
エーシー・リンデム
Adrian Farrel
エイドリアン・ファレル
Aijun Wang
アイジュン・ワン
Daniele Ceccarelli
ダニエレ・セッカレッリ
Dieter Beller
ディーター・ベラー
Jeff Tantsura
ジェフ・タンツラ
Julien Meuric
ジュリエン・ムリック
Liu Hua
Liu Hua
Loa Andersson
ロア・アンダーソン
Luis Miguel Contreras
ルイス・ミゲル・コントレラス
Martin Horneffer
マーティン・ホーンファー
Tarek Saad
タレクサード
Xufeng Liu
Xufeng liu
The production of this document includes a fix to the original text resulting from an errata report #309 [Err309] by Jean-Michel Grimaldi.
このドキュメントの作成には、Jean-Michel GrimaldiによるErrataレポート＃309 [ERR309]から生じる元のテキストの修正が含まれています。
The editor of this document would also like to thank Dhruv Dhody, Gyan Mishra, Joel Halpern, Dave Taht, John Scudder, Rich Salz, Behcet Sarikaya, Bob Briscoe, Erik Kline, Jim Guichard, Martin Duke, and Roman Danyliw for review comments.
このドキュメントの編集者は、Dhruv Dhody、Gyan Mishra、Joel Halpern、Dave Taht、John Scudder、Rich Salz、Behcet Sarikaya、Bob Briscoe、Erik Kline、Jim Guichard、Martin Duke、およびRoman Danyliwにレビューコメントに感謝します。
This work is partially supported by the European Commission under Horizon 2020 grant agreement number 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow).
この作業は、Horizon 2020 Grant契約番号101015857の下で欧州委員会によって部分的にサポートされています。
The following people contributed substantive text to this document:
次の人々は、この文書に実質的なテキストを提供しました。
Gert Grammel
Email: ggrammel@juniper.net
Loa Andersson
Email: loa@pi.nu
Xufeng Liu
Email: xufeng.liu.ietf@gmail.com
Lou Berger
Email: lberger@labn.net
Jeff Tantsura
Email: jefftant.ietf@gmail.com
Daniel King
Email: daniel@olddog.co.uk
Boris Hassanov
Email: bhassanov@yandex-team.ru
Kiran Makhijani
Email: kiranm@futurewei.com
Dhruv Dhody
Email: dhruv.ietf@gmail.com
Mohamed Boucadair
Email: mohamed.boucadair@orange.com
Adrian Farrel (editor)
Old Dog Consulting
Email: adrian@olddog.co.uk