[要約] RFC 7823は、TEメトリック拡張を使用して明示的にルーティングされたラベルスイッチドパス（LSP）のパフォーマンスベースのパス選択に関するものです。その目的は、ネットワークのパフォーマンスを最適化するために、LSPの経路選択においてTEメトリックを使用する方法を提案することです。
Internet Engineering Task Force (IETF) A. Atlas
Request for Comments: 7823 J. Drake
Category: Informational Juniper Networks
ISSN: 2070-1721 S. Giacalone
Microsoft
S. Previdi
Cisco Systems
May 2016
Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
TEメトリック拡張を使用した明示的にルーティングされるラベルスイッチドパス（LSP）のパフォーマンスベースのパス選択
Abstract
概要
In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.
特定のネットワークでは、明示的にルーティングされるRSVP-TEラベルスイッチドパス（LSP）のパスを選択するときに、ネットワークパフォーマンス基準を考慮することが重要です。このようなパフォーマンス基準には、遅延、ジッター、損失、またはリンクパフォーマンス目標への適合性や非RSVP TEトラフィック負荷などの他の指標が含まれます。この仕様では、OSPFおよびIS-IS TEメトリック拡張（このドキュメントの範囲外で定義）を介して通知されるようなパス計算機能がネットワークパフォーマンスデータを使用して、そのようなパス選択を実行する方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7823.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7823で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4
1.2. Oscillation and Stability Considerations . . . . . . . . 4
2. Using Performance Data Constraints . . . . . . . . . . . . . 5
2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5
2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6
2.3. Links out of Compliance with Link Performance Objectives 6
2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7
2.3.2. Links Entering the Anomalous State . . . . . . . . . 7
2.3.3. Links Leaving the Anomalous State . . . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Normative References . . . . . . . . . . . . . . . . . . 8
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
In certain networks, such as financial information networks, network performance information is becoming as critical to data-path selection as other existing metrics. Network performance information can be obtained via either the TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. As with other TE information flooded via OSPF or IS-IS, the TE metric extensions have a flooding scope limited to the local area or level. This document describes how a path computation function, whether in an ingress LSR or a PCE [RFC4655], can use that information for path selection for explicitly routed LSPs. The selected path may be signaled via RSVP-TE [RFC3209] [RFC3473] or simply used by the ingress with segment routing [SEG-ROUTE-MPLS] to properly forward the packet. Methods of optimizing path selection for multiple parameters are generally computationally complex. However, there are good heuristics for the delay-constrained lowest-cost (DCLC) computation problem [k-Paths_DCLC] that can be applied to consider both path cost and a maximum delay bound. Some of the network performance information can also be used to prune links from a topology before computing the path.
財務情報ネットワークなどの特定のネットワークでは、ネットワークパフォーマンス情報は、他の既存のメトリックと同様にデータパス選択にとって重要になってきています。ネットワークパフォーマンス情報は、OSPFのTEメトリック拡張[RFC7471]またはIS-IS [RFC7810]を介して、または管理システムを介して取得できます。 OSPFまたはIS-ISを介してフラッディングされる他のTE情報と同様に、TEメトリック拡張には、ローカルエリアまたはレベルに限定されたフラッディングスコープがあります。このドキュメントでは、入力LSRでもPCE [RFC4655]でも、パス計算機能が明示的にルーティングされたLSPのパス選択にその情報をどのように使用できるかについて説明します。選択されたパスは、RSVP-TE [RFC3209] [RFC3473]を介して通知されるか、またはセグメントルーティングを備えた入口[SEG-ROUTE-MPLS]によって単に使用され、パケットを適切に転送します。複数のパラメーターのパス選択を最適化する方法は、一般に計算が複雑です。ただし、遅延制約付き最小コスト（DCLC）計算問題[k-Paths_DCLC]には、パスコストと最大遅延限界の両方を考慮するために適用できる優れたヒューリスティックがあります。一部のネットワークパフォーマンス情報は、パスを計算する前にトポロジからリンクをプルーニングするためにも使用できます。
The path selection mechanisms described in this document apply to paths that are fully computed by the head-end of the LSP and then signaled in an Explicit Route Object (ERO) where every sub-object is strict. This allows the head-end to consider IGP-distributed performance data without requiring the ability to signal the performance constraints in an object of the RSVP Path message.
このドキュメントで説明するパス選択メカニズムは、LSPのヘッドエンドによって完全に計算され、すべてのサブオブジェクトが厳密な明示的ルートオブジェクト（ERO）で通知されるパスに適用されます。これにより、ヘッドエンドは、RSVPパスメッセージのオブジェクトのパフォーマンス制約を通知する機能を必要とせずに、IGP分散パフォーマンスデータを考慮することができます。
When considering performance-based data, it is obvious that there are additional contributors to latency beyond just the links. Clearly end-to-end latency is a combination of router latency (e.g., latency from traversing a router without queueing delay), queuing latency, physical link latency, and other factors. While traversing a router can cause delay, that router latency can be included in the advertised link delay. As described in [RFC7471] and [RFC7810], queuing delay must not be included in the measurements advertised by OSPF or IS-IS.
パフォーマンスベースのデータを検討する場合、リンクだけでなく、レイテンシに追加の要因があることは明らかです。明らかに、エンドツーエンドのレイテンシは、ルータのレイテンシ（たとえば、キューイング遅延なしでルータを通過することによるレイテンシ）、キューイングレイテンシ、物理リンクレイテンシ、およびその他の要因の組み合わせです。ルータを通過すると遅延が発生する可能性がありますが、そのルータの遅延はアドバタイズされたリンク遅延に含まれる可能性があります。 [RFC7471]と[RFC7810]で説明されているように、OSPFまたはIS-ISによってアドバタイズされる測定には、キューイング遅延を含めないでください。
Queuing latency is specifically excluded to insure freedom from oscillations and stability issues that have plagued prior attempts to use delay as a routing metric. If application traffic follows a path based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop Behavior (PHB) [RFC3246] with minimal queuing delay or another PHB with potentially very substantial per-hop queuing delay. Only traffic that experiences relatively low congestion, such as Expedited Forwarding traffic, will experience delays very close to the sum of the reported link delays.
キューイング遅延は、ルーティングメトリックとして遅延を使用する以前の試みを悩ませてきた発振および安定性の問題からの自由を保証するために特に除外されています。アプリケーショントラフィックが遅延制約に基づくパスをたどる場合、同じトラフィックがキューイング遅延が最小のExpedited Forwarding Per-Hop Behavior（PHB）[RFC3246]であるか、非常に大きなホップごとのキューイング遅延の可能性がある別のPHBである可能性があります。 Expedited Forwardingトラフィックなど、比較的輻輳が少ないトラフィックのみが、報告されたリンク遅延の合計に非常に近い遅延を経験します。
This document does not specify how a router determines what values to advertise by the IGP; it does assume that the constraints specified in [RFC7471] and [RFC7810] are followed. Additionally, the end-to-end performance that is computed for an LSP path should be built from the individual link data. Any end-to-end characterization used to determine an LSP's performance compliance should be fully reflected in the Traffic Engineering Database so that a path calculation can also determine whether a path under consideration would be in compliance.
このドキュメントでは、ルータがIGPによってアドバタイズする値を決定する方法を指定していません。 [RFC7471]と[RFC7810]で指定された制約に従うことを前提としています。さらに、LSPパスに対して計算されるエンドツーエンドのパフォーマンスは、個々のリンクデータから構築する必要があります。 LSPのパフォーマンスコンプライアンスを決定するために使用されるエンドツーエンドの特性評価は、トラフィックエンジニアリングデータベースに完全に反映される必要があります。これにより、パス計算でも、検討中のパスがコンプライアンスに準拠しているかどうかを判断できます。
The following are the requirements considered for a path computation function that uses network performance criteria.
以下は、ネットワークパフォーマンス基準を使用するパス計算機能で考慮される要件です。
1. Select a TE tunnel's path based upon a combination of existing constraints as well as on link-latency, packet loss, jitter, conformance with link performance objectives, and bandwidth consumed by non-RSVP-TE traffic.
1. 既存の制約の組み合わせ、およびリンク遅延、パケット損失、ジッター、リンクパフォーマンス目標への適合性、非RSVP-TEトラフィックによって消費される帯域幅に基づいて、TEトンネルのパスを選択します。
2. Ability to define different end-to-end performance requirements for each TE tunnel regardless of common use of resources.
2. リソースの一般的な使用に関係なく、TEトンネルごとに異なるエンドツーエンドのパフォーマンス要件を定義する機能。
3. Ability to periodically verify with the TE Link State Database (LSDB) that a TE tunnel's current LSP complies with its configured end-to-end performance requirements.
3. TEリンクの現在のLSPが構成されたエンドツーエンドのパフォーマンス要件に準拠していることをTEリンク状態データベース（LSDB）で定期的に確認する機能。
4. Ability to move tunnels, using make-before-break, based upon computed end-to-end performance complying with constraints.
4. 制約に準拠して計算されたエンドツーエンドのパフォーマンスに基づいて、make-before-breakを使用してトンネルを移動する機能。
5. Ability to move tunnels away from any link that is violating an underlying link performance objective.
5. 基礎となるリンクのパフォーマンス目標に違反しているリンクからトンネルを遠ざける機能。
6. Ability to optionally avoid setting up tunnels using any link that is violating a link performance objective, regardless of whether end-to-end performance would still meet requirements.
6. エンドツーエンドのパフォーマンスが要件を満たしているかどうかに関係なく、リンクのパフォーマンス目標に違反しているリンクを使用してトンネルを設定しないようにするオプション。
7. Ability to revert back, using make-before-break, to the best path after a configurable period.
7. make-before-breakを使用して、構成可能な期間後に最適なパスに戻す機能。
Past attempts to use unbounded delay or loss as a metric suffered from severe oscillations. The use of performance based data must be such that undamped oscillations are not possible and stability cannot be impacted.
メトリックとして厳しい制限のない遅延または損失を使用する過去の試みは、激しい振動に悩まされていました。パフォーマンスベースのデータの使用は、減衰されない振動が不可能であり、安定性に影響を与えないようなものでなければなりません。
The use of timers is often cited as a cure. Oscillation that is damped by timers is known as "slosh". If advertisement timers are very short relative to the jitter applied to RSVP-TE Constrained Shortest Path First (CSPF) timers, then a partial oscillation occurs. If RSVP-TE CSPF timers are short relative to advertisement timers, full oscillation (all traffic moving back and forth) can occur. Even a partial oscillation causes unnecessary reordering that is considered at least minimally disruptive.
タイマーの使用はしばしば治療法として引用されます。タイマーによって減衰される振動は「スロッシュ」と呼ばれます。通知タイマーがRSVP-TE Constrained Shortest Path First（CSPF）タイマーに適用されるジッターに比べて非常に短い場合、部分的な発振が発生します。 RSVP-TE CSPFタイマーがアドバタイズタイマーに比べて短い場合、完全な発振（すべてのトラフィックが前後に移動）が発生する可能性があります。部分的な振動でさえ、少なくとも最小限の破壊と見なされる不要な並べ替えを引き起こします。
Delay variation or jitter is affected by even small traffic levels. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter proportional to or equal to the packet serialization delay. Very low levels of traffic can increase the probability of queue occupancies of two or three packets enough to further increase the measured jitter. Because jitter measurement is extremely sensitive to very low traffic levels, any use of jitter is likely to oscillate. However, there may be uses of a jitter measurement in path computation that can be considered free of oscillation.
遅延変動またはジッターは、トラフィックレベルが小さい場合でも影響を受けます。トラフィックレベルが非常に小さい場合でも、キューの占有率が1になる確率により、パケットのシリアル化遅延に比例するか、または等しい遅延が測定されます。トラフィックのレベルが非常に低いと、2つまたは3つのパケットのキュー占有率が増加し、測定されたジッターがさらに増加する可能性があります。ジッタ測定は非常に低いトラフィックレベルに非常に敏感であるため、ジッタを使用すると発振する可能性があります。ただし、発振がないと見なすことができるパス計算でジッタ測定を使用する場合があります。
Delay measurements that are not sensitive to traffic loads may be safely used in path computation. Delay measurements made at the link layer or measurements made at a queuing priority higher than any significant traffic (such as Differentiated Services Code Point (DSCP) CS7 or CS6 [RFC4594], but not CS2 if traffic levels at CS3 and higher or Expedited Forwarding and Assured Forwarding can affect the measurement). Making delay measurements at the same priority as the traffic on affected paths is likely to cause oscillations.
トラフィック負荷の影響を受けない遅延測定は、パス計算で安全に使用できます。リンク層で行われた遅延測定、または重要なトラフィックよりも高いキューイング優先度で行われた測定（Differentiated Services Code Point（DSCP）CS7またはCS6 [RFC4594]など）。ただし、CS3以上のトラフィックレベルまたは優先転送および確実転送は測定に影響を与える可能性があります）。影響を受けるパスのトラフィックと同じ優先度で遅延測定を行うと、発振が発生する可能性があります。
The per-link performance data available in the IGP [RFC7471] [RFC7810] includes: unidirectional link delay, unidirectional delay variation, and link loss. Each (or all) of these parameters can be used to create the path-level link-based parameter.
IGP [RFC7471] [RFC7810]で利用可能なリンクごとのパフォーマンスデータには、単方向リンク遅延、単方向遅延変動、およびリンク損失が含まれます。これらのパラメーターのそれぞれ（またはすべて）を使用して、パスレベルのリンクベースのパラメーターを作成できます。
It is possible to compute a CSPF where the link latency values are used instead of TE metrics; this results in ignoring the TE metrics and causing LSPs to prefer the lowest-latency paths. In practical scenarios, latency constraints are typically a bound constraint rather than a minimization objective. An end-to-end latency upper bound merely requires that the path computed be no more than that bound and does not require that it be the minimum latency path. The latter is exactly the DCLC problem to which good heuristics have been proposed in the literature (e.g., [k-Paths_DCLC]).
TEメトリックの代わりにリンク遅延値が使用されるCSPFを計算することが可能です。これにより、TEメトリックが無視され、LSPが最小の遅延パスを優先するようになります。実際のシナリオでは、レイテンシの制約は通常、最小化の目的ではなく、制限された制約です。エンドツーエンドのレイテンシの上限には、計算されたパスがそのバウンド以下であることだけが必要であり、最小レイテンシパスである必要はありません。後者は、正確なヒューリスティックが文献で提案されているDCLC問題です（たとえば、[k-Paths_DCLC]）。
An end-to-end bound on delay variation can be used similarly as a constraint in the path computation on what links to explore where the path's delay variation is the sum of the used links' delay variations.
遅延変動のエンドツーエンドバウンドは、使用するリンクの遅延変動の合計であるパスの遅延変動がどこにあるかを調べるために、どのリンクに対するパス計算の制約としても使用できます。
For link loss, the path loss is not the sum of the used links' losses. Instead, the path loss fraction is 1 - (1 - loss_L1)* (1 - loss_L2)*...*(1 - loss_Ln), where the links along the path are L1 to Ln with loss_Li in fractions. This computation is discussed in more detail in Sections 5.1.4 and 5.1.5 in [RFC6049]. The end-to-end link loss bound, computed in this fashion, can also be used as a constraint in the path computation.
リンク損失の場合、パス損失は使用済みリンクの損失の合計ではありません。代わりに、パス損失の割合は1-（1-loss_L1）*（1-loss_L2）* ... *（1-loss_Ln）であり、パスに沿ったリンクはL1からLnであり、loss_Liは割合で示されます。この計算については、[RFC6049]のセクション5.1.4および5.1.5で詳しく説明しています。この方法で計算されたエンドツーエンドのリンク損失限界は、パス計算の制約としても使用できます。
The heuristic algorithms for DCLC only address one constraint bound but having a CSPF that limits the paths explored (i.e., based on hop count) can be combined [hop-count_DCLC].
DCLCのヒューリスティックアルゴリズムは、1つの制約境界のみに対処しますが、探索されるパスを制限する（つまり、ホップカウントに基づいて）CSPFを持つことは、[hop-count_DCLC]と組み合わせることができます。
In addition to selecting paths that conform to a bound on performance data, it is also useful to avoid using links that do not meet a necessary constraint. Naturally, if such a parameter were a known fixed value, then resource attribute flags could be used to express this behavior. However, when the parameter associated with a link may vary dynamically, there is not currently a configuration-time mechanism to enforce such behavior. An example of this is described in Section 2.3, where links may move in and out of conformance for link performance objectives with regards to latency, delay variation, and link loss.
パフォーマンスデータの境界に適合するパスを選択することに加えて、必要な制約を満たさないリンクの使用を避けることも役立ちます。当然、そのようなパラメーターが既知の固定値である場合、リソース属性フラグを使用してこの動作を表現できます。ただし、リンクに関連付けられたパラメーターが動的に変化する可能性がある場合、そのような動作を強制する構成時のメカニズムは現在ありません。この例については、セクション2.3で説明します。ここでは、リンクは、待ち時間、遅延変動、およびリンク損失に関して、リンクパフォーマンス目標の適合性に出入りします。
When doing path selection for TE tunnels, it has not been possible to know how much actual bandwidth is available that includes the bandwidth used by non-RSVP-TE traffic. In [RFC7471] and [RFC7810], the Unidirectional Available Bandwidth is advertised as is the Residual Bandwidth. When computing the path for a TE tunnel, only links with at least a minimum amount of Unidirectional Available Bandwidth might be permitted.
TEトンネルのパス選択を行う場合、非RSVP-TEトラフィックで使用される帯域幅を含む実際の帯域幅がどれだけ利用できるかを知ることはできませんでした。 [RFC7471]と[RFC7810]では、単方向の利用可能な帯域幅が、残留帯域幅と同様にアドバタイズされます。 TEトンネルのパスを計算する場合、少なくとも最小量の単方向使用可能帯域幅を持つリンクのみが許可される場合があります。
Similarly, only links whose loss is under a configurable value might be acceptable. For these constraints, each link can be tested against the constraint and only explored in the path computation if the link passes. In essence, a link that fails the constraint test is treated as if it contained a resource attribute in the exclude-any filter.
同様に、損失が設定可能な値を下回っているリンクのみが許容される場合があります。これらの制約の場合、各リンクは制約に対してテストでき、リンクが通過した場合にのみパス計算で探索できます。基本的に、制約テストに失敗したリンクは、exclude-anyフィルターにリソース属性が含まれているかのように扱われます。
Link conformance to a link performance objective can change as a result of rerouting at lower layers. This could be due to optical regrooming or simply rerouting of an FA-LSP. When this occurs, there are two questions to be asked:
リンクのパフォーマンス目標へのリンクの適合性は、下位層での再ルーティングの結果として変化する可能性があります。これは、光の再調整または単にFA-LSPの再ルーティングが原因である可能性があります。これが発生した場合、2つの質問をする必要があります。
a. Should the link be trusted and used for the setup of new LSPs?
a. リンクを信頼して新しいLSPのセットアップに使用する必要がありますか？
b. Should LSPs using this link automatically be moved to a secondary path?
b. このリンクを使用するLSPを自動的にセカンダリパスに移動する必要がありますか？
If the answer to (a) is no for link latency performance objectives, then any link that has the Anomalous bit set in the Unidirectional Link Delay sub-TLV [RFC7471] [RFC7810] should be removed from the topology before a path calculation is used to compute a new path. In essence, the link should be treated exactly as if it fails the exclude-any resource attributes filter [RFC3209].
（a）に対する答えがリンクレイテンシパフォーマンス目標に当てはまらない場合、パス計算を使用する前に、単方向リンク遅延サブTLV [RFC7471] [RFC7810]で異常ビットが設定されているリンクをトポロジから削除する必要があります。新しいパスを計算します。本質的には、リンクはexclude-anyリソース属性フィルター[RFC3209]に失敗した場合とまったく同じように処理する必要があります。
Similarly, if the answer to (a) is no for link loss performance objectives, then any link that has the Anomalous bit set in the Link Loss sub-TLV should be treated as if it fails the exclude-any resource attributes filter.
同様に、（a）に対する答えがリンク損失パフォーマンス目標に当てはまらない場合、リンク損失サブTLVで異常ビットが設定されているリンクは、exclude-anyリソース属性フィルターに失敗した場合と同様に処理する必要があります。
When the Anomalous bit transitions from clear to set, this indicates that the associated link has entered the Anomalous state with respect to the associated parameter; similarly, a transition from set to clear indicates that the Anomalous state has been exited for that link and associated parameter.
異常ビットがクリアからセットに移行する場合、これは関連するリンクが関連するパラメーターに関して異常な状態に入ったことを示します。同様に、setからclearへの遷移は、そのリンクおよび関連するパラメーターの異常状態が終了したことを示します。
When a link enters the Anomalous state with respect to a parameter, this is an indication that LSPs using that link might also no longer be in compliance with their performance bounds. It can also be considered an indication that something is changing that link and so it might no longer be trustworthy to carry performance-critical traffic. Naturally, which performance criteria are important for a particular LSP is dependent upon the LSP's configuration; thus, the compliance of a link with respect to a particular link performance objective is indicated per performance criterion.
リンクがパラメーターに関して異常な状態になると、これは、そのリンクを使用するLSPもパフォーマンスの限界に準拠していない可能性があることを示しています。また、何かがそのリンクを変更しているため、パフォーマンスが重要なトラフィックを伝送することが信頼できなくなっている可能性もあります。当然、特定のLSPにとってどのパフォーマンス基準が重要であるかは、LSPの構成に依存します。したがって、特定のリンクパフォーマンス目標に関するリンクのコンプライアンスは、パフォーマンス基準ごとに示されます。
At the ingress of a TE tunnel, a TE tunnel may be configured to be sensitive to the Anomalous state of links in reference to latency, delay variation, and/or loss. Additionally, such a TE tunnel may be configured to either verify continued compliance, to switch immediately to a standby LSP, or to move to a different path.
TEトンネルの入口で、TEトンネルは、遅延、遅延変動、および/または損失に関して、リンクの異常状態に敏感になるように構成できます。さらに、このようなTEトンネルは、継続的なコンプライアンスを確認するか、すぐにスタンバイLSPに切り替えるか、別のパスに移動するように構成できます。
When a sub-TLV is received with the Anomalous bit set when previously it was clear, the list of interested TE tunnels must be scanned. Each such TE tunnel should have its continued compliance verified, be switched to a hot standby, or do a make-before-break to a secondary path.
以前はクリアであったときに異常ビットが設定された状態でサブTLVを受信した場合、関係するTEトンネルのリストをスキャンする必要があります。このような各TEトンネルでは、継続的なコンプライアンスの検証、ホットスタンバイへの切り替え、またはセカンダリパスへのメイクビフォアブレイクを行う必要があります。
It is not sufficient to just look at the Anomalous bit in order to determine when TE tunnels must have their compliance verified. When changing to set, the Anomalous bit merely provides a hint that interested TE tunnels should have their continued compliance verified.
TEトンネルのコンプライアンスを検証する必要がある場合を判断するには、異常ビットを調べるだけでは不十分です。セットに変更すると、異常ビットは、関心のあるTEトンネルが継続的なコンプライアンスを検証する必要があるというヒントを提供するだけです。
When a link leaves the Anomalous state with respect to a parameter, this can serve as an indication that those TE tunnels, whose LSPs were changed due to administrative policy when the link entered the Anomalous state, may want to reoptimize to a better path. The hint provided by the Anomalous state change may help optimize when to recompute for a better path.
リンクがパラメータに関して異常状態を離れるとき、これは、リンクが異常状態になったときに管理ポリシーのためにLSPが変更されたTEトンネルが、より適切なパスに再最適化することを示す可能性があることを示します。 Anomalous状態変更によって提供されるヒントは、より適切なパスを再計算するタイミングを最適化するのに役立ちます。
This document is not currently believed to introduce new security concerns.
このドキュメントは現在、新しいセキュリティ上の懸念をもたらすとは考えられていません。
[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, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[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, <http://www.rfc-editor.org/info/rfc7471>.
[RFC7471] Giacalone、S.、Ward、D.、Drake、J.、Atlas、A。、およびS. Previdi、「OSPF Traffic Engineering（TE）Metric Extensions」、RFC 7471、DOI 10.17487 / RFC7471、2015年3月、 <http://www.rfc-editor.org/info/rfc7471>。
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/7810, May 2016, <http://www.rfc-editor.org/info/rfc7810>.
[RFC7810] Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J.、and Q. Wu、 "IS-IS Traffic Engineering（TE）Metric Extensions"、RFC 7810、DOI 10.17487 / 7810、2016年5月、<http://www.rfc-editor.org/info/rfc7810>。
[hop-count_DCLC] Agrawal, H., Grah, M., and M. Gregory, "Optimization of QoS Routing", 6th IEEE/AACIS International Conference on Computer and Information Science, DOI 10.1109/ICIS.2007.144, July 2007, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=4276447>.
[hop-count_DCLC] Agrawal、H.、Grah、M。、およびM. Gregory、「QoSルーティングの最適化」、第6回IEEE / AACISコンピュータおよび情報科学国際会議、DOI 10.1109 / ICIS.2007.144、2007年7月、< http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber = 4276447>。
[k-Paths_DCLC] Jia, Z. and P. Varaiya, "Heuristic methods for delay constrained least cost routing using k-shortest-paths", IEEE Transactions on Automatic Control, vol. 51, no. 4, April 2006, <http://dx.doi.org/10.1109/TAC.2006.872827>.
[k-Paths_DCLC] Jia、Z。およびP. Varaiya、「k-shortest-pathsを使用した遅延制約付き最小コストルーティングのヒューリスティック手法」、IEEE Transactions on Automatic Control、vol。 51、いいえ。 2006年4月4日、<http://dx.doi.org/10.1109/TAC.2006.872827>。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <http://www.rfc-editor.org/info/rfc3246>.
[RFC3246]デイビー、B、チャーニー、A、ベネット、J、ベンソン、K、ルブーデック、J、コートニー、W、ダヴァリ、S、フィロイ、V、およびDスティリアディス、 Expedited Forwarding PHB（Per-Hop Behavior）」、RFC 3246、DOI 10.17487 / RFC3246、2002年3月、<http://www.rfc-editor.org/info/rfc3246>。
[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, <http://www.rfc-editor.org/info/rfc3473>.
[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、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594]バビアス、J。、チャン、K。、およびF.ベイカー、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<http://www.rfc-editor.org / info / rfc4594>。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：//www.rfc -editor.org/info/rfc4655>。
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <http://www.rfc-editor.org/info/rfc6049>.
[RFC6049] Morton、A。およびE. Stephan、「メトリックの空間構成」、RFC 6049、DOI 10.17487 / RFC6049、2011年1月、<http://www.rfc-editor.org/info/rfc6049>。
[SEG-ROUTE-MPLS] Filsfils, C., Ed., Previdi, S., Ed., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-04, March 2016.
[SEG-ROUTE-MPLS] Filsfils、C。、編、Previdi、S。、編、Bashandy、A.、Decraene、B.、Litkowski、S.、Horneffer、M.、Shakir、R.、Tantsura、 J.およびE. Crabbe、「MPLSデータプレーンを使用したセグメントルーティング」、作業中、draft-ietf-spring-segment-routing-mpls-04、2016年3月。
Acknowledgements
謝辞
The authors would like to thank Curtis Villamizar for his extensive detailed comments and suggested text in Sections 1 and 1.2. The authors would like to thank Dhruv Dhody for his useful comments and his care and persistence in making sure that these important corrections weren't missed. The authors would also like to thank Xiaohu Xu and Sriganesh Kini for their reviews.
著者は、Curtis Villamizarの広範な詳細なコメントとセクション1および1.2の提案テキストに感謝します。著者は、これらの重要な修正を見逃さないようにしてくれた彼の有用なコメントと彼の注意と粘り強さについて、Dhruv Dhodyに感謝します。著者は、Xiaohu XuとSriganesh Kiniのレビューにも感謝します。
Contributors
貢献者
Dave Ward and Clarence Filsfils contributed to this document.
Dave WardとClarence Filsfilsがこのドキュメントに貢献しました。
Authors' Addresses
著者のアドレス
Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States
Alia Atlas Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: akatlas@juniper.net
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: jdrake@juniper.net
Spencer Giacalone Microsoft
スペンサージャカロンマイクロソフト
Email: spencer.giacalone@gmail.com
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 00142 Italy
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 00142イタリア
Email: sprevidi@cisco.com