[要約] RFC 8426は、RSVP-TEとSegment Routing（SR）のLSPの共存に関する推奨事項を提供しています。このRFCの目的は、RSVP-TEとSRのLSPを効果的に統合するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) H. Sitaraman, Ed.
Request for Comments: 8426 V. Beeram
Category: Informational Juniper Networks
ISSN: 2070-1721 I. Minei
Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
July 2018
Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
RSVP-TEとセグメントルーティング（SR）ラベルスイッチドパス（LSP）の共存に関する推奨事項
Abstract
概要
Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.
オペレーターは、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）LSPを実行しているネットワークで、セグメントルーティング（SR）ラベルスイッチドパス（LSP）を介したサービスの導入を検討しています。場合によっては、事業者が既存のサービスをRSVP-TEからSR LSPに移行することもあります。たとえば、SRに適しており、同じネットワークでRSVP-TEと共存する必要がある特定のサービスがある場合があります。このようなSRへのトラフィックの導入または移行では、オペレーターの意図によっては、同じネットワーク内でRSVP-TEと長期間共存する必要があります。次のドキュメントは、SRとRSVP-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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8426.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8426で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Solution Options . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Static Partitioning of Bandwidth . . . . . . . . . . . . 4
3.2. Centralized Management of Available Capacity . . . . . . 4
3.3. Flooding SR Utilization in IGP . . . . . . . . . . . . . 5
3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5
3.5. TED Consistency by Reflecting SR Traffic . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Multiplier Value Range . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Introduction of SR [RFC8402] in the same network domain as RSVP-TE [RFC3209] presents the problem of accounting for SR traffic and making RSVP-TE aware of the actual available bandwidth on the network links. RSVP-TE is not aware of how much bandwidth is being consumed by SR services on the network links; hence, both at computation time (for a distributed computation) and at signaling time, RSVP-TE LSPs will incorrectly place loads. This is true where RSVP-TE paths are distributed or centrally computed without a common entity managing both SR and RSVP-TE computation for the entire network domain.
RSVP-TE [RFC3209]と同じネットワークドメインにSR [RFC8402]を導入すると、SRトラフィックを考慮し、RSVP-TEにネットワークリンクで実際に利用可能な帯域幅を認識させるという問題が生じます。 RSVP-TEは、ネットワークリンク上のSRサービスによって消費されている帯域幅を認識していません。したがって、計算時（分散計算の場合）とシグナリング時の両方で、RSVP-TE LSPは誤って負荷をかけます。これは、RSVP-TEパスが分散されるか、ネットワークドメイン全体のSRとRSVP-TEの両方の計算を管理する共通のエンティティなしで集中的に計算される場合に当てはまります。
The problem space can be generalized as a dark bandwidth problem to cases where any other service exists in the network that runs in parallel across common links and whose bandwidth is not reflected in the available and reserved values in the Traffic Engineering Database (TED). In most practical instances, given the static nature of the traffic demands, limiting the reservable bandwidth available to RSVP-TE has been an acceptable solution. However, in the case of SR traffic, there is assumed to be very dynamic traffic demands, and there is considerable risk associated with stranding capacity or overbooking service traffic resulting in traffic drops.
問題空間は、一般的なリンクを介して並列に実行され、その帯域幅がトラフィックエンジニアリングデータベース（TED）の利用可能な予約済みの値に反映されていない他のサービスがネットワークに存在する場合に、暗い帯域幅の問題として一般化できます。ほとんどの実際的な例では、トラフィック要求の静的な性質を考えると、RSVP-TEが利用できる予約可能な帯域幅を制限することは、許容できるソリューションでした。ただし、SRトラフィックの場合、非常に動的なトラフィックの需要があると想定され、容量のストランディングまたはサービストラフィックのオーバーブッキングに関連するかなりのリスクがあり、その結果、トラフィックがドロップします。
The high-level requirements to consider are:
考慮すべき高レベルの要件は次のとおりです。
1. Placement of SR LSPs in the same domain as RSVP-TE LSPs must not introduce inaccuracies in the TED used by distributed or centralized path computation engines.
1. RSVP-TE LSPと同じドメインにSR LSPを配置しても、分散型または集中型パス計算エンジンで使用されるTEDに不正確さが生じてはなりません。
2. Engines that compute RSVP-TE paths may have no knowledge of the existence of the SR paths in the same domain.
2. RSVP-TEパスを計算するエンジンは、同じドメインにSRパスが存在することを認識していない場合があります。
3. Engines that compute RSVP-TE paths should not require a software upgrade or change to their path-computation logic.
3. RSVP-TEパスを計算するエンジンでは、ソフトウェアのアップグレードやパス計算ロジックの変更は必要ありません。
4. Protocol extensions should be avoided or be minimal as, in many cases, this coexistence of RSVP-TE and SR may be needed only during a transition phase.
4. 多くの場合、このRSVP-TEとSRの共存は移行フェーズでのみ必要になる可能性があるため、プロトコル拡張は回避するか最小限にする必要があります。
5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are computed in a distributed fashion must not require migration to a central controller architecture for the RSVP-TE LSPs.
5. 分散方式で計算されるRSVP-TE LSPと同じドメインにSR LSPを配置する場合、RSVP-TE LSPの中央コントローラーアーキテクチャに移行する必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following section lists SR and RSVP coexistence solution options. A specific solution is not recommended as all solutions are valid, even though some may not satisfy all the requirements. If a solution is acceptable for an operator based on their deployment model, then such a solution can be chosen.
次のセクションでは、SRとRSVPの共存ソリューションオプションを示します。一部のソリューションがすべての要件を満たしていない場合でも、すべてのソリューションが有効であるため、特定のソリューションは推奨されません。ソリューションが運用モデルに基づいてオペレーターに受け入れられる場合、そのようなソリューションを選択できます。
In this model, the static reservable bandwidth of an interface can be statically partitioned between SR and RSVP-TE; each one can operate within that bandwidth allocation and SHOULD NOT preempt the other.
このモデルでは、インターフェイスの静的予約可能帯域幅をSRとRSVP-TEの間で静的に分割できます。それぞれがその帯域幅割り当て内で動作でき、もう一方を優先使用してはなりません（SHOULD NOT）。
While it is possible to configure RSVP-TE to only reserve up to a certain maximum link bandwidth and manage the remaining link bandwidth for other services, this is a deployment where SR and RSVP-TE are separated in the same network (ships in the night) and can lead to suboptimal link bandwidth utilization not allowing each to consume more, if required and constraining the respective deployments.
特定の最大リンク帯域幅のみを予約して他のサービスのために残りのリンク帯域幅を管理するようにRSVP-TEを構成することは可能ですが、これはSRとRSVP-TEが同じネットワークで分離された展開です（夜の船） ）そして、必要に応じて、リンク帯域幅の使用率が最適ではなく、それぞれがより多くを消費することを許可せず、それぞれの展開を制約する可能性があります。
The downside of this approach is the inability to use the reservable bandwidth effectively and the inability to use bandwidth left unused by the other protocol.
このアプローチの欠点は、予約可能な帯域幅を効果的に使用できないことと、他のプロトコルで使用されていないままの帯域幅を使用できないことです。
In this model, a central controller performs path placement for both RSVP-TE and SR LSPs. The controller manages and updates its own view of the in-use and available capacity. As the controller is a single common entity managing the network it can have a unified and consistent view of the available capacity at all times.
このモデルでは、中央コントローラーがRSVP-TEとSR LSPの両方のパス配置を実行します。コントローラは、使用中および使用可能な容量に関する独自のビューを管理および更新します。コントローラはネットワークを管理する単一の共通エンティティであるため、常に利用可能な容量の統一された一貫したビューを持つことができます。
A practical drawback of this model is that it requires the introduction of a central controller managing the RSVP-TE LSPs as a prerequisite to the deployment of any SR LSPs. Therefore, this approach is not practical for networks where distributed TE with RSVP-TE LSPs is already deployed, as it requires a redesign of the network and is not backwards compatible. This does not satisfy requirement 5.
このモデルの実際的な欠点は、SR LSPの展開の前提条件として、RSVP-TE LSPを管理する中央コントローラーの導入が必要なことです。したがって、このアプローチは、ネットワークの再設計が必要であり、下位互換性がないため、RSVP-TE LSPを使用した分散型TEがすでに展開されているネットワークでは実用的ではありません。これは要件5を満たしていません。
Note that it is not enough for the controller to just maintain the unified view of the available capacity, it must also perform the path computation for the RSVP-TE LSPs, as the reservations for the SR LSPs are not reflected in the TED.
SR LSPの予約はTEDに反映されないため、コントローラは使用可能な容量の統一されたビューを維持するだけでは十分ではなく、RSVP-TE LSPのパス計算も実行する必要があることに注意してください。
Using techniques in [RFC7810], [RFC7471], and [RFC7823], the SR utilization information can be flooded in IGP-TE, and the RSVP-TE path computation engine (Constrained Shortest Path First (CSPF)) can be changed to consider this information. This requires changes to the RSVP-TE path computation logic and would require upgrades in deployments where distributed computation is done across the network.
[RFC7810]、[RFC7471]、および[RFC7823]の手法を使用して、SR使用率情報をIGP-TEにフラッディングし、RSVP-TEパス計算エンジン（Constrained Shortest Path First（CSPF））を変更して検討できます。この情報。これには、RSVP-TEパス計算ロジックの変更が必要であり、ネットワーク全体で分散計算が行われる展開ではアップグレードが必要になります。
This does not fit with requirements 3 and 4 mentioned earlier.
これは、前述の要件3および4には適合しません。
SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. In this model, the LSPs can be one-hop or multi-hop and can provide bandwidth reservation for the SR traffic based on functionality such as auto-bandwidth. The model of deployment would be similar in nature to running LDP over RSVP-TE. This would allow the TED to stay consistent across the network and any other RSVP-TE LSPs will also be aware of the SR traffic reservations. In this approach, non-SR traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required by policy.
SRは、SRトラフィックのみを伝送する専用RSVP-TE LSPで実行できます。このモデルでは、LSPは1ホップまたはマルチホップにすることができ、自動帯域幅などの機能に基づいてSRトラフィックに帯域幅予約を提供できます。展開のモデルは、RSVP-TE上でLDPを実行するのと本質的に似ています。これにより、TEDはネットワーク全体で一貫性を保つことができ、他のRSVP-TE LSPもSRトラフィックの予約を認識します。このアプローチでは、ポリシーで要求されない限り、非SRトラフィックはSR専用のRSVP-TE LSPを使用してはなりません（MUST NOT）。
The drawback of this solution is that it requires SR to rely on RSVP-TE for deployment. Furthermore, the accounting accuracy/frequency of this method is dependent on performance of auto-bandwidth for RSVP-TE. Note that, for this method to work, the SR-dedicated RSVP-TE LSPs must be set up with the best setup and hold priorities in the network.
このソリューションの欠点は、SRVPが展開のためにRSVP-TEに依存する必要があることです。さらに、この方法のアカウンティング精度/頻度は、RSVP-TEの自動帯域幅のパフォーマンスに依存します。この方法が機能するためには、SR専用のRSVP-TE LSPがネットワークで最適なセットアップとホールドプライオリティでセットアップされている必要があります。
The solution relies on dynamically measuring SR traffic utilization on each TE interface and reducing the bandwidth allowed for use by RSVP-TE. It is assumed that SR traffic receives precedence in terms of the placement on the path over RSVP traffic (that is, RSVP traffic can be preempted from the path in case of insufficient resources). This is logically equivalent to SR traffic having the best preemption priority in the network. Note that this does not necessarily mean that SR traffic has higher QoS priority; in fact, SR and RSVP traffic may be in the same QoS class.
このソリューションは、各TEインターフェイスのSRトラフィック使用率を動的に測定し、RSVP-TEが使用できる帯域幅を削減することに依存しています。 SRVPトラフィックは、RSVPトラフィックよりもパス上の配置の点で優先されると想定されます（つまり、リソースが不十分な場合は、RSVPトラフィックをパスから差し替えることができます）。これは、ネットワーク内でプリエンプションの優先順位が最も高いSRトラフィックと論理的に同等です。これは必ずしもSRトラフィックがより高いQoS優先順位を持つことを意味するわけではないことに注意してください。実際、SRトラフィックとRSVPトラフィックは同じQoSクラスに属している可能性があります。
Reducing the bandwidth allowed for use by RSVP-TE can be explored using the three parameters available in IGP-TE ([RFC5305] [RFC3630]), namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth, and Unreserved-Bandwidth.
RSVP-TEで使用できる帯域幅の削減は、IGP-TEで使用可能な3つのパラメーター（[RFC5305] [RFC3630]）、つまり、最大リンク帯域幅、最大予約可能帯域幅、および未予約帯域幅を使用して調べることができます。
o Maximum-Link-Bandwidth: This parameter can be adjusted to accommodate the bandwidth required for SR traffic with cascading impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth. However, changing the maximum bandwidth for the TE link will prevent any compute engine for SR or RSVP from determining the real static bandwidth of the TE link. Further, when the Maximum-Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth, its definition changes since Maximum-Link-Bandwidth will account for the SR traffic.
o 最大リンク帯域幅：このパラメータは、SRトラフィックに必要な帯域幅に対応するように調整でき、最大予約可能帯域幅と最大予約帯域幅にカスケード効果があります。ただし、TEリンクの最大帯域幅を変更すると、SRまたはRSVPの計算エンジンがTEリンクの実際の静的帯域幅を決定できなくなります。さらに、Maximum-Reservable-BandwidthがMaximum-Link-Bandwidthから導出される場合、Maximum-Link-BandwidthがSRトラフィックを考慮に入れるため、その定義が変更されます。
o Unreserved-Bandwidth: SR traffic could directly adjust the Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or Maximum-Reservable-Bandwidth. This model is equivalent to the option described in Section 3.4. Furthermore this would result in overloading IGP-TE advertisements to directly reflect both RSVP-TE bandwidth bookings and SR bandwidth measurements.
o Unreserved-Bandwidth：SRトラフィックは、Maximum-Link-BandwidthまたはMaximum-Reservable-Bandwidthに影響を与えることなく、Unreserved-Bandwidthを直接調整できます。このモデルは、セクション3.4で説明されているオプションに相当します。さらに、これによりIGP-TEアドバタイズが過負荷になり、RSVP-TE帯域幅予約とSR帯域幅測定の両方が直接反映されます。
o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic could adjust the Maximum-Reservable-Bandwidth, with cascading impact on the Unreserved-Bandwidth.
o 最大予約可能帯域幅：推奨オプションとして、SRトラフィックは最大予約可能帯域幅を調整でき、非予約帯域幅に段階的な影響を与えます。
The following methodology can be used at every TE node for this solution, using the following parameters:
次のパラメータを使用して、このソリューションのすべてのTEノードで次の方法を使用できます。
o T: Traffic statistics collection time interval.
o T：トラフィック統計収集時間間隔。
o k: The number of traffic statistics samples that can provide a smoothing function to the statistics collection. The value of k is a constant integer multiplier greater or equal to 1.
o k：統計収集に平滑化機能を提供できるトラフィック統計サンプルの数。 kの値は、1以上の定数の整数乗数です。
o N: Traffic averaging calculation (adjustment) interval such that N = k * T.
o N：N = k * Tとなるようなトラフィック平均計算（調整）間隔。
o Maximum-Reservable-Bandwidth: The maximum available bandwidth for RSVP-TE.
o 最大予約可能帯域幅：RSVP-TEで使用可能な最大帯域幅。
o If Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable-Bandwidth SHOULD be interpreted as the aggregate bandwidth constraint across all Class-Types independent of the Bandwidth Constraints model.
o Diffserv対応のMPLSトラフィックエンジニアリング（DS-TE）[RFC4124]が有効になっている場合、最大予約可能帯域幅は、帯域幅制約モデルとは無関係に、すべてのクラスタイプにわたる総帯域幅制約として解釈される必要があります（SHOULD）。
o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable-bandwidth for TE when no SR traffic or RSVP-TE reservations exist on the interface.
o Initial Maximum-Reservable-Bandwidth：SRトラフィックまたはRSVP-TE予約がインターフェイスに存在しない場合のTEの最大予約可能帯域幅。
o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable-Bandwidth - sum of (existing reservations at priority X and all priorities better than X).
o RSVP-unreserved-bandwidth-at-priority-X：Maximum-Reservable-Bandwidth-合計（優先度Xの既存の予約とXよりも優れたすべての優先度）。
o SR traffic threshold percentage: The percentage difference of traffic demand that, when exceeded, can result in a change to the RSVP-TE Maximum-Reservable-Bandwidth.
o SRトラフィックしきい値パーセンテージ：超過した場合にRSVP-TE最大予約可能帯域幅が変更される可能性があるトラフィックデマンドのパーセンテージの差。
o IGP-TE update threshold: Specifies the frequency at which IGP-TE updates should be triggered based on TE bandwidth updates on a link.
o IGP-TE更新しきい値：リンク上のTE帯域幅更新に基づいてIGP-TE更新がトリガーされる頻度を指定します。
o M: An optional multiplier that can be applied to the SR traffic average. This multiplier provides the ability to grow or shrink the bandwidth used by SR. Appendix A offers further guidance on M.
o M：SRトラフィック平均に適用できるオプションの乗数。この乗数は、SRが使用する帯域幅を拡大または縮小する機能を提供します。付録Aは、Mに関するさらなるガイダンスを提供します。
At every interval T, each node SHOULD collect the SR traffic statistics for each of its TE interfaces. The measured SR traffic includes all labeled SR traffic and any traffic entering the SR network over that TE interface. Further, at every interval N, given a configured SR traffic threshold percentage and a set of collected SR traffic statistics samples across the interval N, the SR traffic average (or any other traffic metric depending on the algorithm used) over this period is calculated. This method of sampling traffic statistics and adjusting bandwidth reservation accordingly is similar to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs.
すべての間隔Tで、各ノードは、TEインターフェイスごとにSRトラフィック統計を収集する必要があります（SHOULD）。測定されたSRトラフィックには、すべてのラベル付きSRトラフィックと、そのTEインターフェイスを介してSRネットワークに入るトラフィックが含まれます。さらに、間隔Nごとに、構成されたSRトラフィックしきい値パーセンテージと、間隔Nにわたって収集されたSRトラフィック統計サンプルのセットが与えられると、この期間のSRトラフィック平均（または使用されるアルゴリズムに応じて他のトラフィックメトリック）が計算されます。トラフィック統計をサンプリングし、それに応じて帯域幅予約を調整するこの方法は、自動帯域幅RSVP-TE LSPの帯域幅を調整する方法と似ています。
If the difference between the new calculated SR traffic average and the current SR traffic average (that was computed in the prior adjustment) is at least SR traffic threshold percentage, then two values MUST be updated:
新しく計算されたSRトラフィック平均と現在のSRトラフィック平均（前の調整で計算された）の差が少なくともSRトラフィックしきい値の割合である場合、2つの値を更新する必要があります。
o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable-Bandwidth - (new SR traffic average * M)
o 新しい最大予約可能帯域幅=初期最大予約可能帯域幅-（新しいSRトラフィック平均* M）
o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum-Reservable-Bandwidth - sum of (existing reservations at priority X and all priorities better than X)
o 新しいRSVP-unreserved-bandwidth-at-priority-X =新しいMaximum-Reservable-Bandwidth-の合計（優先度Xの既存の予約とXよりも優れたすべての優先度）
A DS-TE LSR that advertises a Bandwidth Constraints TLV should update the bandwidth constraints for class-types based on operator policy. For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then only BC0 may be updated. Whereas, when Maximum Allocation Model (MAM) [RFC4125] is in use, then all Bandwidth Constraints (BCs) may be updated equally such that the total value updated is equal to the newly calculated SR traffic average.
帯域幅制約TLVを通知するDS-TE LSRは、オペレーターポリシーに基づいてクラスタイプの帯域幅制約を更新する必要があります。たとえば、Russian Dolls Model（RDM）[RFC4127]が使用されている場合、BC0のみが更新されます。一方、最大割り当てモデル（MAM）[RFC4125]が使用されている場合、更新された合計値が新しく計算されたSRトラフィック平均と等しくなるように、すべての帯域幅制約（BC）が等しく更新されます。
Note that the computation of the new RSVP-unreserved-bandwidth-at-priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. Such preemption will be based on relative priority (e.g., low to high) between RSVP-TE LSPs. The IGP-TE update threshold SHOULD allow for more frequent flooding of unreserved bandwidth. From an operational point of view, an implementation SHOULD be able to expose both the configured and the actual values of the Maximum-Reservable-Bandwidth.
新しいRSVP-unreserved-bandwidth-at-priority-Xの計算により、RSVP-TE LSPがハードまたはソフトで横取りされる可能性があることに注意してください。そのようなプリエンプションは、RSVP-TE LSP間の相対的な優先度（低から高など）に基づきます。 IGP-TE更新しきい値は、予約されていない帯域幅のフラッディングをより頻繁に許可する必要があります（SHOULD）。運用の観点から、実装は、最大予約可能帯域幅の構成された値と実際の値の両方を公開できる必要があります（SHOULD）。
If LSP preemption is not acceptable, then the RSVP-TE Maximum-Reservable-Bandwidth cannot be reduced below what is currently reserved by RSVP-TE on that interface. This may result in bandwidth not being available for SR traffic. Thus, it is required that any external controller managing SR LSPs SHOULD be able to detect this situation (for example, by subscribing to TED updates [RFC7752]) and SHOULD take action to reroute existing SR paths.
LSPプリエンプションが受け入れられない場合、RSVP-TE Maximum-Reservable-Bandwidthを、そのインターフェイスでRSVP-TEによって現在予約されている帯域幅よりも小さくすることはできません。これにより、SRトラフィックに帯域幅を使用できない場合があります。したがって、SR LSPを管理するすべての外部コントローラがこの状況を検出できる必要があり（たとえば、TED更新[RFC7752]にサブスクライブすることにより）、既存のSRパスを再ルーティングするアクションを実行する必要があります（SHOULD）。
Generically, SR traffic (or any non-RSVP-TE traffic) should have its own priority allocated from the available priorities. This would allow SR to preempt other traffic according to the preemption priority order.
一般に、SRトラフィック（または非RSVP-TEトラフィック）には、使用可能な優先度から独自の優先度を割り当てる必要があります。これにより、SRはプリエンプションの優先順位に従って他のトラフィックをプリエンプトできます。
In this solution, the logic to retrieve the statistics, calculating averages and taking action to change the Maximum-Reservable-Bandwidth is an implementation choice, and all changes are local in nature. However, note that this is a new network trigger for RSVP-TE preemption and thus is a consideration for the operator.
このソリューションでは、統計を取得し、平均を計算し、Maximum-Reservable-Bandwidthを変更するためのアクションを実行するロジックは実装の選択であり、すべての変更は本質的にローカルです。ただし、これはRSVP-TEプリエンプションのための新しいネットワークトリガーであり、オペレーターにとっては考慮事項であることに注意してください。
The above solution offers the advantage of not introducing new network-wide mechanisms especially during scenarios of migrating to SR in an existing RSVP-TE network and reusing existing protocol mechanisms.
上記のソリューションには、特に既存のRSVP-TEネットワークでSRに移行し、既存のプロトコルメカニズムを再利用するシナリオでは、新しいネットワーク全体のメカニズムを導入しないという利点があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document describes solution options for the coexistence of RSVP-TE and SR LSPs in the same administrative domain. The security considerations for SR are described in [RFC8402]. The security considerations pertaining to RSVP-TE are described in [RFC5920]. The security considerations of each architecture are typically unaffected by the presence of the other. However, when RSVP-TE and SR LSPs coexist, it is possible for a hijacked SR traffic stream to maliciously consume sufficient bandwidth and cause disruption to RSVP-TE LSPs. With the solution option specified in Section 3.5, the impact to RSVP-TE traffic can be controlled and paths re-routed. Some latent risk of disruption still remains because this solution option relies on taking statistics samples and adopting to new traffic flows only after the adjustment period. The defensive mechanisms described in the base SR security framework should be employed to guard against situations that result in SR traffic hijacking or denial of service.
このドキュメントでは、同じ管理ドメインでRSVP-TEとSR LSPを共存させるためのソリューションオプションについて説明します。 SRのセキュリティに関する考慮事項は、[RFC8402]で説明されています。 RSVP-TEに関連するセキュリティの考慮事項は、[RFC5920]で説明されています。各アーキテクチャのセキュリティに関する考慮事項は、通常、他のアーキテクチャの存在による影響を受けません。ただし、RSVP-TEとSR LSPが共存している場合、ハイジャックされたSRトラフィックストリームが悪意を持って十分な帯域幅を消費し、RSVP-TE LSPに混乱を引き起こす可能性があります。セクション3.5で指定されたソリューションオプションを使用すると、RSVP-TEトラフィックへの影響を制御し、パスを再ルーティングできます。このソリューションオプションは統計サンプルの取得と調整期間後の新しいトラフィックフローの採用に依存しているため、混乱の潜在的なリスクがまだ残っています。 SRトラフィックのハイジャックまたはサービス拒否の原因となる状況から保護するために、ベースSRセキュリティフレームワークで説明されている防御メカニズムを採用する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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>.
[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月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[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>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[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>.
[RFC4124] Le Faucheur、F。、編、「Diffserv対応のMPLSトラフィックエンジニアリングをサポートするためのプロトコル拡張」、RFC 4124、DOI 10.17487 / RFC4124、2005年6月、<https://www.rfc-editor.org/ info / rfc4124>。
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, <https://www.rfc-editor.org/info/rfc4125>.
[RFC4125] Le Faucheur、F。およびW. Lai、「Diffserv対応MPLSトラフィックエンジニアリングの最大割り当て帯域幅制約モデル」、RFC 4125、DOI 10.17487 / RFC4125、2005年6月、<https：//www.rfc-editor。 org / info / rfc4125>。
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, DOI 10.17487/RFC4127, June 2005, <https://www.rfc-editor.org/info/rfc4127>.
[RFC4127] Le Faucheur、F。、編、「Diffserv対応のMPLSトラフィックエンジニアリングのためのロシアの人形の帯域幅制約モデル」、RFC 4127、DOI 10.17487 / RFC4127、2005年6月、<https://www.rfc-editor.org / info / rfc4127>。
[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>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https://www.rfc-editor.org/info/rfc5305> 。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[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>.
[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月、 <https://www.rfc-editor.org/info/rfc7471>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[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/RFC7810, May 2016, <https://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 / RFC7810、2016年5月、<https://www.rfc-editor.org/info/rfc7810>。
[RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, "Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions", RFC 7823, DOI 10.17487/RFC7823, May 2016, <https://www.rfc-editor.org/info/rfc7823>.
[RFC7823] Atlas、A.、Drake、J.、Giacarone、S。、およびS. Previdi、「TEメトリック拡張を使用した明示的にルーティングされるラベルスイッチドパス（LSP）のパフォーマンスベースのパス選択」、RFC 7823、DOI 10.17487 / RFC7823、2016年5月、<https://www.rfc-editor.org/info/rfc7823>。
The following is a suggestion for the range of values for M:
以下は、Mの値の範囲に関する提案です。
M is a per-node positive real number that ranges from 0 to 2 with a default of 1 and may be expressed as a percentage.
Mはノードごとの正の実数で、デフォルトは1で0から2の範囲で、パーセンテージで表すことができます。
o If M < 1, then the SR traffic average is being understated, which can result in the link getting full even though Maximum-Reservable-Bandwidth does not reach zero.
o M <1の場合、SRトラフィック平均は過小評価されているため、Maximum-Reservable-Bandwidthがゼロに達していなくてもリンクがいっぱいになる可能性があります。
o If M > 1, then the SR traffic average is overstated, thereby resulting in the Maximum-Reservable-Bandwidth reaching zero before the link gets full. If the reduction of Maximum-Reservable-Bandwidth becomes a negative value, then a value of zero SHOULD be used and advertised.
o M> 1の場合、SRトラフィック平均は誇張されているため、リンクがいっぱいになる前に最大予約可能帯域幅がゼロに達します。 Maximum-Reservable-Bandwidthの削減が負の値になる場合は、ゼロの値を使用してアドバタイズする必要があります（SHOULD）。
Acknowledgements
謝辞
The authors would like to thank Steve Ulrich for his detailed review and comments.
著者は彼の詳細なレビューとコメントをしてくれたSteve Ulrichに感謝したいと思います。
Contributors
貢献者
Chandra Ramachandran Juniper Networks Email: csekar@juniper.net
チャンドララマチャンドランジュニパーネットワークスメール：csekar@juniper.net
Raveendra Torvi Juniper Networks Email: rtorvi@juniper.net
Raveendra Torvi Juniper Networksメール：rtorvi@juniper.net
Sudharsana Venkataraman Juniper Networks Email: sudharsana@juniper.net
Sudharsana Venkataraman Juniper Networksメール：sudharsana@juniper.net
Martin Vigoureux Nokia Email: martin.vigoureux@nokia.com
Martin Vigoureux Nokiaメール：martin.vigoureux@nokia.com
Authors' Addresses
著者のアドレス
Harish Sitaraman (editor) Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Harish Sitaraman（編集者）Juniper Networks 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国
Email: hsitaraman@juniper.net
Vishnu Pavan Beeram Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Vishnu Pavan Beeram Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: vbeeram@juniper.net
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: inaminei@google.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Shiva Sivabalan Cisco Systems、Inc. ೨೦೦೦革新的なドライブドライブ、オンタリオQ1 A ೮カナダ
Email: msiva@cisco.com