[要約] RFC 5712は、MPLSトラフィックエンジニアリングのソフトプリエンプションに関する規格です。その目的は、ネットワークのリソースを効果的に管理し、優先度の高いトラフィックに対して優先的な処理を行うことです。
Internet Engineering Task Force (IETF) M. Meyer, Ed.
Request for Comments: 5712 British Telecom
Category: Standards Track JP. Vasseur, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
January 2010
MPLS Traffic Engineering Soft Preemption
MPLSトラフィックエンジニアリングソフトプリエンプション
Abstract
概要
This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities.
このドキュメントは、マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリングソフトプリエンプションを指定しています。これは、先制交通エンジニアリングラベルスイッチ付きパス（TE LSP）のトラフィック破壊を削減または排除することを目的として、先制の概念を拡張する一連のプロトコル変更です。当初、MPLS RSVP-TEは、先制時に即時のTE LSP変位のみをサポートして定義されました。Rerouteリクエスト通知の利用は、先制型TE LSPのルアウトプロセスをより優雅に緩和するのに役立ちます。短い期間にソフトプリエンプションがアクティブになりますが、TE LSPが再ルーティングできるまで、予約（必ずしも交通レベルではありませんが）が事実上不足しています。このため、この機能は、差別化されたサービスとトラフィックエンジニアリング機能を備えたMPLS対応のIPネットワークでは、主に排他的ではなく興味深いものではありません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5712.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5712で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Acronyms and Abbreviations .................................3
2.2. Nomenclature ...............................................4
2.3. Requirements Language ......................................4
3. Motivations .....................................................4
4. RSVP Extensions .................................................5
4.1. SESSION-ATTRIBUTE Flags ....................................5
4.2. Path Error - "Reroute Request Soft Preemption"
Error Value ................................................5
5. Mode of Operation ...............................................6
6. Elements Of Procedures ..........................................7
6.1. On a Soft Preempting LSR ...................................7
6.2. On Head-end LSR of a Soft Preempted TE LSP .................9
7. Interoperability ...............................................10
8. Management .....................................................10
9. IANA Considerations ............................................11
9.1. New Session Attribute Object Flag .........................11
9.2. New Error Sub-Code Value ..................................11
10. Security Considerations .......................................11
11. Acknowledgements ..............................................12
12. Contributors ..................................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................13
In a Multiprotocol Label Switching (MPLS) Resource Reservation Protocol Traffic Engineering (RSVP-TE) (see [RFC3209]) enabled IP network, hard preemption is the default behavior. Hard preemption provides no mechanism to allow preempted Traffic Engineering Label Switched Paths (TE LSPs) to be handled in a make-before-break fashion: the hard preemption scheme instead utilizes a very intrusive method that can cause traffic disruption for a potentially large amount of TE LSPs. Without an alternative, network operators either accept this limitation, or remove functionality by using only one preemption priority or using invalid bandwidth reservation values. Understandably desirable features like TE reservation adjustments that are automated by the ingress Label Edge Router (LER) are less palatable when preemption is intrusive and maintaining high levels of network stability levels is a concern.
マルチプロトコルラベルスイッチング（MPLS）リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）（[RFC3209]を参照）有効なIPネットワークでは、ハードプリエンプションがデフォルトの動作です。ハードプリエンプションは、先制交通エンジニアリングラベルスイッチ付きパス（TE LSP）をブレイク前に処理できるようにするメカニズムを提供しません。te lsps。代替品がないと、ネットワークオペレーターはこの制限を受け入れるか、1つの先制優先度のみを使用して機能を削除するか、無効な帯域幅の予約値を使用して機能を削除します。Ingressラベルエッジルーター（LER）によって自動化されるTE予約調整のような当然のことながら望ましい機能は、先制が邪魔になっていて、高レベルのネットワーク安定性レベルを維持することは懸念事項です。
This document defines the use of additional signaling and maintenance mechanisms to alert the ingress LER of the preemption that is pending and allow for temporary control-plane under-provisioning while the preempted tunnel is rerouted in a non-disruptive fashion (make-before-break) by the ingress LER. During the period that the tunnel is being rerouted, link capacity is under-provisioned on the midpoint where preemption initiated and potentially one or more links upstream along the path where other soft preemptions may have occurred.
このドキュメントでは、追加のシグナル伝達およびメンテナンスメカニズムの使用を定義して、保留中の先制の侵入を警告し、先制トンネルが破壊的でない方法で再ルーティングされている間に一時的な制御面の不足を許可します（壊れてから壊れます。）侵入lerによって。トンネルが再ルーティングされている期間中、リンク容量は、先制が開始された中間点で不足しており、他のソフトな先制が発生した可能性のある経路に沿って上流に1つ以上のリンクを潜在的に1つ以上のリンクを潜在的に繰り返します。
This document follows the nomenclature of the MPLS Architecture defined in [RFC3031].
このドキュメントは、[RFC3031]で定義されているMPLSアーキテクチャの命名法に従います。
CSPF: Constrained Shortest Path First.
CSPF：最初に最短パスを制約します。
DS: Differentiated Services.
DS：差別化されたサービス。
LER: Label Edge Router.
LER：ラベルエッジルーター。
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
LSP: Label Switched Path.
LSP：ラベルスイッチ付きパス。
MPLS: MultiProtocol Label Switching.
MPLS：マルチプロトコルラベルスイッチング。
RSVP: Resource ReSerVation Protocol.
RSVP：リソース予約プロトコル。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルの切り替えパス。
Point of Preemption - the midpoint or ingress LSR which due to RSVP provisioning levels is forced to either hard preempt or under-provision and signal soft preemption.
Point of Preemption -RSVPのプロビジョニングレベルが強制的に強制的またはプロビジョニング不足と信号のソフトプリエンプションを強制される中間点または侵入LSR。
Hard Preemption - The (typically default) preemption process in which higher numeric priority TE LSPs are intrusively displaced at the point of preemption by lower numeric priority TE LSPs. In hard preemption, the TE LSP is torn down before reestablishment.
ハードプリエンプション - （通常はデフォルトの）先制プロセスが、数値優先度TE LSPによってより高い数値優先度TE LSPが先制の時点で内部的に変位します。ハードプリエンプションでは、TE LSPは再確立される前に取り壊されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Initially, MPLS RSVP-TE [RFC3209] was defined with support for only one method of TE LSP preemption, which immediately tears down TE LSPs, disregarding the preempted in-transit traffic. This simple but abrupt process nearly guarantees preempted traffic will be discarded, if only briefly, until the RSVP Path Error message reaches and is processed by the ingress LER and a new data path can be established. The Error Code and Error Values carried within the RSVP Path Error message to report a preemption action are documented in [RFC5711]. Note that such preemption is also referred to as a fatal error in [RFC5711]. In cases of actual resource contention this might be helpful; however, preemption may be triggered by mere reservation contention, and reservations may not reflect data-plane contention up to the moment. The result is that when conditions that promote preemption exist and hard preemption is the default behavior, inferior priority preempted traffic may be needlessly discarded when sufficient bandwidth exists for both the preempted TE LSP and the preempting TE LSP(s).
当初、MPLS RSVP-TE [RFC3209]は、TE LSPの先制の1つの方法のみをサポートして定義されていました。このシンプルだが突然のプロセスは、RSVPパスエラーメッセージが到達し、イングレスLERによって処理され、新しいデータパスが確立されるまで、一時的にのみ破棄されたトラフィックが破棄されることをほぼ保証します。RSVPパスエラーメッセージ内で搭載されたエラーコードとエラー値は、[RFC5711]に文書化されています。そのような先制は[RFC5711]の致命的な誤差とも呼ばれることに注意してください。実際のリソースの競合の場合、これは役立つかもしれません。ただし、先制は単なる予約競合によって引き起こされる可能性があり、予約はその瞬間までのデータ面の競合を反映しない場合があります。その結果、先制を促進する条件が存在し、ハードプリエンプションがデフォルトの動作が存在する場合、プリエンプトされたTE LSPと先制TE LSP（S）の両方に十分な帯域幅が存在する場合、劣る優先度の先制トラフィックが不必要に破棄される可能性があります。
Hard preemption may be a requirement to protect numerically lower preemption priority traffic in a non-Diffserv-enabled architecture, but in a Diffserv-enabled-architecture, one need not rely exclusively upon preemption to enforce a preference for the most valued traffic since the marking and queuing disciplines should already be aligned for those purposes. Moreover, even in non-Diffserv-aware networks, depending on the TE LSP sizing rules (imagine all LSPs are sized at double their observed traffic level), reservation contention may not accurately reflect the potential for data-plane congestion.
ハードプリエンプションは、非ディフェルサーブ対応アーキテクチャでの数値的に低い先制優先トラフィックを保護するための要件である可能性がありますが、拡散対応アーキテクチャでは、マーキング以来、最も価値のあるトラフィックの好みを実施するために先制際に独占的に依存する必要はありません。そして、これらの目的のために、キューイングの分野はすでに整合する必要があります。さらに、TE LSPサイズのルール（すべてのLSPが観察されたトラフィックレベルの2倍にサイズがあることを想像してください）に応じて、Diffservを認識していないネットワークであっても、予約の競合はデータプレーンの混雑の可能性を正確に反映していない可能性があります。
To explicitly signal the desire for a TE LSP to benefit from the soft preemption mechanism (and thus not to be hard preempted if the soft preemption mechanism is available), the following flag of the SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined:
TE LSPがソフトプリエンプションメカニズムの恩恵を受けること（したがって、ソフトプリエンプションメカニズムが利用可能である場合、ハードプリエンプト化されない）の恩恵を明示的に信号するために、セッションアトリビューングオブジェクトの次のフラグ（両方のCタイプ1についておよび7）定義されています：
Soft Preemption Desired bit
ソフトプリエンプションが望むビット
Bit Flag Name Flag 0x40 Soft Preemption Desired
ビットフラグ名フラグ0x40ソフトプリエンプション希望
[RFC5710] specifies defines a new reroute-specific error code that allows a midpoint to report a TE LSP reroute request (Error Code=34 - Reroute). This document specifies a new Error Value sub-code for the case of soft preemption.
[RFC5710]指定MidpointがTE LSP Rerouteリクエストを報告できる新しいReroute固有のエラーコードを定義します（エラーコード= 34 -Reroute）。このドキュメントは、ソフトプリエンプションの場合の新しいエラー値サブコードを指定します。
Error-value Meaning Reference
1 Reroute Request Soft Preemption This document
Upon (soft) preemption, the preempting node MUST issue a PathErr message with the Error Code=34 ("Reroute") and a value=1 ("Reroute Request Soft Preemption").
（ソフト）先制では、プリエンプトノードはエラーコード= 34（ "Reroute"）と値= 1（ "Reroute Request Soft Preemption"）でpatherrメッセージを発行する必要があります。
Let's consider the following example:
次の例を考えてみましょう。
R0--1G--R1---155----R2
| \ |
| \ 155
| \ |
155 1G R3
| \ |
| \ 155
| \|
R4----1G----R5
LSP1: LSP2:
LSP1：LSP2：
R0-->R1 R1<--R2
\ |
V V
R5 R4
Figure 1: Example of Soft Preemption Operation
図1：ソフトプリエンプション操作の例
In the network depicted above in Figure 1, consider the following conditions:
上記の図1に示すネットワークでは、次の条件を検討してください。
o Reservable BW on R0-R1, R1-R5, and R4-R5 is 1 Gbit/s.
o R0-R1、R1-R5、およびR4-R5の予約可能なBWは1 gbit/sです。
o Reservable BW on R1-R2, R1-R4, R2-R3, and R3-R5 is 155 Mbit/s.
o R1-R2、R1-R4、R2-R3、およびR3-R5の予約可能なBWは155 Mbit/sです。
o Bandwidths and costs are identical in both directions.
o 帯域幅とコストは、両方向で同一です。
o Each circuit has an IGP metric of 10, and the IGP metric is used by CSPF.
o 各回路のIGPメトリックは10で、IGPメトリックはCSPFによって使用されます。
o Two TE tunnels are defined:
o 2つのTEトンネルが定義されています。
* LSP1: 155 Mbit/s, setup/hold priority 0 tunnel, path R0-R1-R5.
* LSP1：155 Mbit/s、セットアップ/ホールド優先度0トンネル、パスR0-R1-R5。
* LSP2: 155 Mbit/s, setup/hold priority 7 tunnel, path R2-R1-R4.
* LSP2：155 Mbit/s、セットアップ/ホールド優先度7トンネル、パスR2-R1-R4。
Both TE LSPs are signaled with the "Soft Preemption Desired" bit of their SESSION-ATTRIBUTE object set.
両方のTE LSPは、セッションアトリブオブジェクトセットの「ソフトプリエンプションが望む」ビットで信号を送られます。
o Circuit R1-R5 fails.
o 回路R1-R5は失敗します。
o Soft Preemption is functional.
o ソフトプリエンプションは機能的です。
When the circuit R1-R5 fails, R1 detects the failure and sends an updated IGP LSA/LSP and Path Error message to all the head-end LSRs that have a TE LSP traversing the failed link (R0 in the example above). Either form of notification may arrive at the head-end LSRs first. Upon receiving the link failure notification, R0 triggers a TE LSP reroute of LSP1, and re-signals LSP1 along shortest path available satisfying the TE LSP constraints: R0-R1-R4-R5 path. The Resv messages for LSP1 travel in the upstream direction (from the destination to the head-end LSR -- R5 to R0 in this example). LSP2 is soft preempted at R1 as it has a numerically lower priority value, and both bandwidth reservations cannot be satisfied on the R1-R4 link.
回路R1-R5が失敗すると、R1は障害を検出し、更新されたIGP LSA/LSPとパスエラーメッセージを送信します。どちらの形式の通知が最初にヘッドエンドLSRに到着する場合があります。リンク障害通知を受信すると、R0はLSP1のTE LSP Rerouteをトリガーし、TE LSPの制約を満たす最短パスに沿ってLSP1を再署名します：R0-R1-R4-R5パス。LSP1のRESVメッセージは、上流の方向に移動します（この例では、宛先からヘッドエンドLSR-R5からR0まで）。LSP2は、数値的に低い優先度値を持つため、R1でソフトプリエンプトされており、R1-R4リンクでは両方の帯域幅の予約を満たすことができません。
Instead of sending a PathTear message for LSP2 upon preemption as with hard preemption (which would result in an immediate traffic disruption for LSP2), R1's local bandwidth accounting for LSP2 is zeroed, and a PathErr message with error code "Reroute" and a value "Reroute Request Soft Preemption" for LSP2 is issued.
ハードプリエンプション（LSP2の即時トラフィックの破壊につながる）と同様に、先制時にLSP2のPATHTEARメッセージを送信する代わりに、R1のLSP2を占めるローカル帯域幅はゼロになり、エラーコード「Reroute」とA Value」を備えたPatherRメッセージがゼロになります。LSP2のリクエストソフトプリエンプションが発行されました。
Upon reception of the PathErr message for LSP2, R2 may update the working copy of the TE-DB before calculating a new path for the new LSP. In the case that Diffserv [RFC3270] and TE [RFC3209] are deployed, receiving a "preemption pending" notification may imply to a head-end LSR that the available bandwidth for the affected priority level and numerically greater priority levels has been exhausted for the indicated node interface. R2 may choose to reduce or zero the available bandwidth for the implied priority range until more accurate information is available (i.e., a new IGP TE update is received). It follows that R2 re-computes a new path and performs a non-traffic-disruptive rerouting of the new TE LSP T2 by means of the make-before-break procedure. The old path is then torn down.
LSP2のPATHERRメッセージを受信すると、R2は新しいLSPの新しいパスを計算する前に、TE-DBの作業コピーを更新する場合があります。Diffserv [RFC3270]およびTE [RFC3209]が展開されている場合、「先制保留中」通知を受け取ることは、影響を受けた優先レベルで利用可能な帯域幅と数値的に大きな優先レベルが排出されていることをヘッドエンドLSRに意味する場合があります。示されたノードインターフェイス。R2は、より正確な情報が利用可能になるまで、暗黙の優先範囲範囲で使用可能な帯域幅を減らすかゼロにすることを選択できます（つまり、新しいIGP TEアップデートが受信されます）。その結果、R2は新しいパスを再計算し、破壊前の手順を使用して新しいTE LSP T2のトラフィック破壊的な再脱出を実行します。その後、古い道が取り壊されます。
When a new TE LSP is signaled that requires a set of TE LSP(s) to be preempted because not all TE LSPs can be accommodated on a specific interface, a node triggers a preemption action that consists of selecting the set of TE LSPs that must be preempted so as to free up some bandwidth in order to satisfy the newly signaled numerically lower preemption TE LSP.
すべてのTE LSPを特定のインターフェイスに収容できるわけではないため、TE LSPのセットを先取りする必要がある新しいTE LSPがシグナルを受ける場合、ノードは、必要なTE LSPのセットを選択することで構成される先制アクションをトリガーします。新たにシグナルが数値的に低い先制TE LSPを満たすために、帯域幅を解放するように先取りしてください。
With hard preemption, when a TE LSP is preempted, the preempting node sends an RSVP PathErr message that serves as notification of a fatal action as documented in [RFC5711]. Upon receiving the RSVP PathErr message, the head-end LSR sends an RSVP PathTear message, that would result in an immediate traffic disruption for the preempted TE LSP.
ハードプリエンプションで、TE LSPが先制されると、先制ノードは[RFC5711]に記録されているように致命的な行動の通知として機能するRSVP PATHERRメッセージを送信します。RSVP Patherrメッセージを受信すると、ヘッドエンドLSRはRSVP PathTearメッセージを送信します。
By contrast, the mode of operation with soft preemption is as follows: the preempting node's local bandwidth accounting for the preempted TE LSP is zeroed and a PathErr with error code "Reroute", and a error value "Reroute Request Soft Preemption" for that TE LSP is issued upstream toward the head-end LSR.
対照的に、ソフトプリエンプションを使用した動作モードは次のとおりです。先制ノードのローカル帯域幅はゼロになり、エラーコード「Reroute」とエラー値「reluoute request request requestion "relute for this"）を備えたpatherrがゼロになります。LSPは、ヘッドエンドLSRに向かって上流に発行されます。
If more than one soft preempted TE LSP has the same head-end LSR, these soft preemption PathErr notification messages may be bundled together.
複数のソフトプリエンプトTE LSPが同じヘッドエンドLSRを持っている場合、これらのソフトプリエンプションPATHERR通知メッセージは一緒にバンドルされる可能性があります。
The preempting node MUST immediately send a PathErr with error code "Reroute" and a error value "Reroute Request Soft Preemption" for each soft preempted TE LSP. The node MAY use the occurrence of soft preemption to trigger an immediate IGP update or influence the scheduling of an IGP update.
プリエンプトノードは、エラーコード「Reroute」とエラー値「ReRoute Request Soft Preemption」を備えたPatherrをすぐに送信する必要があります。ノードは、ソフトプリエンプションの発生を使用して、即時のIGP更新をトリガーするか、IGP更新のスケジューリングに影響を与える場合があります。
To guard against a situation where bandwidth under-provisioning will last forever, a local timer (named the "Soft preemption timer") MUST be started on the preemption node upon soft preemption. If this timer expires, the preempting node SHOULD send an RSVP PathTear and either a ResvTear message or a PathErr with the 'Path_State_Removed' flag set.
帯域幅の過小評価が永遠に続く状況を防ぐには、ローカルタイマー（「ソフトプリエンプションタイマー」と呼ばれる）を、ソフトプリエンプション時に先制ノードで開始する必要があります。このタイマーが期限切れになった場合、PreemptingノードはRSVP PATHTEARとresvTearメッセージまたは「path_state_removed」フラグセットを備えたpatherrを送信する必要があります。
Should a refresh event for a soft preempted TE LSP arrive before the soft preemption timer expires, the soft preempting node MUST continue to refresh the TE LSP.
ソフトプリエンプションTE LSPのリフレッシュイベントがソフトプリエンプションタイマーの有効期限が切れる前に到着した場合、ソフトプリエンプトノードはTE LSPを更新し続ける必要があります。
When the MESSAGE-ID extensions defined in [RFC2961] are available and enabled, PathErr messages with the error code "Reroute" and error value "Reroute Request Soft Preemption" SHOULD be sent in reliable mode.
[RFC2961]で定義されているメッセージ-IDエクステンションが利用可能で有効になったら、エラーコード「Reroute」とエラー値「REROUTE REQUEST SOFT PREENTION」を含むPatherRメッセージは信頼できるモードで送信する必要があります。
The preempting node MAY preempt TE LSPs that have a numerically higher Holding priority than the Setup priority of the newly admitted LSP. Within the same priority, first it SHOULD attempt to preempt LSPs with the "Soft Preemption Desired" bit of the SESSION ATTRIBUTE object cleared, i.e., the TE LSPs that are considered as Hard Preemptable.
先制ノードは、新たに認められたLSPのセットアップ優先度よりも数値的に高い保持優先度を持つLSPを先取りする場合があります。同じ優先順位の範囲内で、最初に、Clearedがクリアされたセッション属性オブジェクトの「ソフトプリエンプション」ビット、つまりハードプリエンプトと見なされるTE LSPでLSPを先取りしようとする必要があります。
Selection of the preempted TE LSP at a preempting midpoint: when a numerically lower priority TE LSP is signaled that requires the preemption of a set of numerically higher priority LSPs, the node where preemption is to occur has to make a decision on the set of TE LSP(s) that are candidates for preemption. This decision is a local decision and various algorithms can be used, depending on the objective (e.g, see [RFC4829]). As already mentioned, soft preemption causes a temporary link under-provisioning condition while the soft preempted TE LSPs are rerouted by their respective head-end LSRs. In order to reduce this under-provisioning exposure, a soft preempting LSR MAY check first if there exists soft preemptable TE LSP bandwidth that is flagged by another node but still available for soft preemption locally. If sufficient overlap bandwidth exists, the LSR MAY attempt to soft preempt the same TE LSP. This would help reduce the temporarily elevated under-provisioning ratio on the links where soft preemption occurs and reduce the number of preempted TE LSPs. Optionally, a midpoint LSR upstream or downstream from a soft preempting node MAY choose to flag the TE LSPs in soft preempted state. In the event a local preemption is needed, the LSPs that are in the cache and of the relevant priority level are soft preempted first, followed by the normal soft and hard preemption selection process for the given priority.
先制の前点での先行式TE LSPの選択：数値的に高い優先度LSPの先制を必要とする数値的に低い優先度TE LSPがシグナル伝達されると、先制が発生するノードがTEのセットを決定する必要があります先制の候補者であるLSP。この決定はローカルな決定であり、目的に応じてさまざまなアルゴリズムを使用できます（例：[RFC4829]を参照）。すでに述べたように、柔らかい先制は一時的なリンク不足条件を引き起こしますが、ソフトな先制のTE LSPはそれぞれのヘッドエンドLSRによって再ルーティングされます。このプロビジョニング不足の曝露を減らすために、ソフトな先制LSRは、別のノードによってフラグが付けられているが、局所的にソフトプリエンプションに使用できるソフトな先制のTE LSP帯域幅が存在するかどうかを最初に確認する場合があります。十分なオーバーラップ帯域幅が存在する場合、LSRは同じTE LSPを柔らかく先取りしようとする場合があります。これは、ソフトプリエンプションが発生するリンクの一時的に上昇した不足の不足比率を減らし、先制測定されたTE LSPの数を減らすのに役立ちます。オプションで、ソフトプリエンプトノードから上流または下流の中間点LSRまたは下流では、ソフトな先制状態のTE LSPにフラグを立てることができます。ローカルな先制が必要な場合、キャッシュ内で関連する優先度レベルのLSPが最初にソフトプリエンプトされ、その後、与えられた優先度のための通常のソフトおよびハードプリエンプション選択プロセスが続きます。
Under specific circumstances such as unacceptable link congestion, a node MAY decide to hard preempt a TE LSP (by sending a fatal Path Error message, a PathTear, and either a ResvTear or a Path Error message with the 'Path_State_Removed' flag set) even if its head-end LSR explicitly requested soft preemption (by setting the "Soft Preemption Desired" flag of the corresponding SESSION-ATTRIBUTE object). Note that such a decision MAY also be made for TE LSPs under soft preemption state.
容認できないリンクの混雑などの特定の状況では、ノードはTE LSP（致命的なパスエラーメッセージ、PATHTEAR、および「PATH_STATE_REMOVED 'フラグセット」を使用したresVTEARまたはパスエラーメッセージのいずれかを送信することにより）を処理することを決定する場合があります。そのヘッドエンドLSRは、ソフトプリエンプションを明示的に要求しました（対応するセッションアトリブオブジェクトの「ソフトプリエンプションが望む」フラグを設定することにより）。このような決定は、ソフトプリエンプション状態の下でのTe LSPに対しても行われる可能性があることに注意してください。
Upon reception of a PathErr message with error code "Reroute" and an error value "Reroute request soft preemption", the head-end LSR MAY first update the working copy of the TE-DB before computing a new path (e.g., by running CSPF) for the new LSP. In the case that Diffserv [RFC3270] and MPLS Traffic Engineering [RFC3209] are deployed, receiving "preemption pending" may imply to a head-end LSR that the available bandwidth for the affected priority level and numerically greater priority levels has been exhausted for the indicated node interface. A head-end LSR MAY choose to reduce or zero the available bandwidth for the implied priority range until more accurate information is available (i.e., a new IGP TE update is received).
エラーコード「Reroute」とエラー値「Reroute Request Soft Preemption」を使用してPatherRメッセージを受信すると、ヘッドエンドLSRは、新しいパスを計算する前にTE-DBの作業コピーを最初に更新することができます（例：CSPFを実行することで）新しいLSP用。diffserv [RFC3270]およびMPLSトラフィックエンジニアリング[RFC3209]が展開されている場合、「先制保留中」を受け取ることは、影響を受ける優先レベルで利用可能な帯域幅と数値的に大きな優先レベルが排出されていることをヘッドエンドLSRに意味する可能性があります。示されたノードインターフェイス。ヘッドエンドLSRは、より正確な情報が利用可能になるまで、暗黙の優先範囲範囲で利用可能な帯域幅を減らすかゼロにすることを選択できます（つまり、新しいIGP TEアップデートが受信されます）。
Once a new path has been computed, the soft preempted TE LSP is rerouted using the non-traffic-disruptive make-before-break procedure. The amount of time the head-end node avoids using the node interface identified by the IP address contained in the PathErr is based on a local decision at the head-end node.
新しいパスが計算されると、柔らかい先制TE LSPは、トラフィックの破壊的なメイク前の手順を使用して再ルーティングされます。ヘッドエンドノードがPATHERRに含まれるIPアドレスによって識別されたノードインターフェイスの使用を避ける時間の量は、ヘッドエンドノードのローカル決定に基づいています。
As a result of soft preemption, no traffic will be needlessly black-holed due to mere reservation contention. If loss is to occur, it will be due only to an actual traffic congestion scenario and according to the operator's Diffserv (if Diffserv is deployed) and queuing scheme.
柔らかい先制の結果として、単なる予約競合のために不必要に黒穴がありません。損失が発生する場合、実際の交通渋滞シナリオのみが原因で、オペレーターのdiffserv（diffservが展開されている場合）およびキューイングスキームに従って行われます。
Backward compatibility should be assured as long as the implementation followed the recommendations set forth in [RFC3209].
[RFC3209]に記載されている推奨事項に従っていれば、後方互換性を保証する必要があります。
As mentioned previously, to guard against a situation where bandwidth under-provisioning will last forever, a local timer (soft preemption timer) MUST be started on the preemption node upon soft preemption. When this timer expires, the soft preempted TE LSP SHOULD be hard preempted by sending a fatal Path Error message, a PathTear message, and either a ResvTear message or a PathErr message with the 'Path_State_Removed' flag set. This timer SHOULD be configurable, and a default value of 30 seconds is RECOMMENDED.
前述のように、帯域幅の下部プロビジョニングが永遠に続く状況を防ぐには、ローカルタイマー（ソフトプリエンプションタイマー）を、ソフトプリエンプション時に先制ノードで開始する必要があります。このタイマーが期限切れになると、致命的なパスエラーメッセージ、PATHTEARメッセージ、および「PATH_STATE_REMOVED」フラグセットを使用したresVTEARメッセージまたはpatherRメッセージのいずれかを送信することにより、ソフトプリエンプトTE LSPをハードプリエンプトする必要があります。このタイマーは構成可能である必要があり、30秒のデフォルト値が推奨されます。
It is RECOMMENDED that configuring the default preemption timer to 0 will cause the implementation to use hard-preemption.
デフォルトのプリエンプションタイマーを0に設定すると、実装がハードプリエンプションを使用することをお勧めします。
Soft preemption as defined in this document is designed for use in MPLS RSVP-TE enabled IP networks and may not functionally translate to some GMPLS technologies. As with backward compatibility, if a device does not recognize a flag, it should pass the subobject transparently.
このドキュメントで定義されているソフトプリエンプションは、MPLS RSVP-TE対応のIPネットワークで使用するように設計されており、一部のGMPLSテクノロジーに機能的に翻訳されない場合があります。後方互換性と同様に、デバイスがフラグを認識しない場合、サブオブジェクトを透過的に渡す必要があります。
Both the point of preemption and the ingress LER SHOULD provide some form of accounting internally and to the network operator interface with regard to which TE LSPs and how much capacity is under-provisioned due to soft preemption. Displays of under-provisioning are recommended for the following midpoint, ingress, and egress views:
先制のポイントとイングレスLERの両方は、どのTE LSPと、ソフトプリエンプションのためにどの程度の容量がプロビジョニングされているかに関して、内部的に何らかの形の会計を提供する必要があります。以下の中間点、入り口、出力ビューには、プロビジョニング不足の表示が推奨されます。
o Sum of current bandwidth per preemption priority per local interface
o ローカルインターフェイスごとのプリエンプションあたりの現在の帯域幅の合計
o Sum of current bandwidth total per local interface
o ローカルインターフェイスごとの電流帯域幅の合計
o Sum of current bandwidth per local router (ingress, egress, midpoint)
o ローカルルーターあたりの電流帯域幅の合計（イングレス、出口、中点）
o List of current LSPs and bandwidth in PPend (preemption pending) status
o PPENDの現在のLSPと帯域幅のリスト（保留中）ステータス
o List of current sum bandwidth and session count in PPend status per observed Explicit Route Object (ERO) hops (ingress and egress views only).
o 観測された明示的なルートオブジェクト（ERO）ホップごとのPPENDステータスの現在の合計帯域幅とセッションカウントのリスト（イングレスビューと出口ビューのみ）。
o Cumulative PPend events per observed ERO hop.
o 観測されたEROホップごとの累積PPENDイベント。
A new flag of the Session Attribute Object has been registered by IANA.
セッション属性オブジェクトの新しいフラグがIANAによって登録されています。
Soft Preemption Desired bit
ソフトプリエンプションが望むビット
Bit Flag Name Reference
0x40 Soft Preemption Desired This document
[RFC5710] defines a new reroute-specific error code that allows a midpoint to report a TE LSP reroute request. This document specifies a new error sub-code value for the case of Soft Preemption.
[RFC5710]は、ミッドポイントがTE LSP Rerouteリクエストを報告できる新しいReroute固有のエラーコードを定義します。このドキュメントは、ソフトプリエンプションの場合の新しいエラーサブコード値を指定します。
Error-value Meaning Reference
1 Reroute Request Soft Preemption This document
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC3209] remain relevant. Further details about MPLS security considerations can be found in [SEC_FMWK].
このドキュメントでは、新しいセキュリティの問題は導入されていません。元のRSVPプロトコル[RFC3209]に関連するセキュリティ上の考慮事項は引き続き関連しています。MPLSセキュリティに関する考慮事項の詳細については、[SEC_FMWK]をご覧ください。
As noted in Section 6.1, soft preemption may result in temporary link under provisioning condition while the soft preempted TE LSPs are rerouted by their respective head-end LSRs. Although this is a less serious condition than false hard preemption, and despite the mitigation procedures described in Section 6.1, network operators should be aware of the risk to their network in the case that the soft preemption processes are subverted, and should apply the relevant MPLS control plane security techniques to protect against attacks.
セクション6.1で述べたように、ソフトプリエンプションはプロビジョニング条件下で一時的なリンクをもたらす可能性がありますが、ソフトプリエンプトTE LSPはそれぞれのヘッドエンドLSRによって再ルーティングされます。これは偽のハードプリエンプションよりも深刻な条件ではありませんが、セクション6.1で説明されている緩和手順にもかかわらず、ネットワークオペレーターは、ソフトプリエンプションプロセスが破壊されている場合にネットワークのリスクを認識し、関連するMPLSを適用する必要があります。攻撃から保護するためのプレーンのセキュリティ手法を制御します。
The authors would like to thank Carol Iturralde, Dave Cooper, Loa Andersson, Arthi Ayyangar, Ina Minei, George Swallow, Adrian Farrel, and Mustapha Aissaoui for their valuable comments.
著者は、キャロル・イトゥルラルド、デイブ・クーパー、ロア・アンダーソン、アルティ・アヤンガル、イナ・ミネイ、ジョージ・スワロー、エイドリアン・ファレル、ムスタファ・アイサウイに貴重なコメントに感謝したいと思います。
Denver Maddux Limelight Networks USA EMail: denver@nitrous.net
デンバー・マドゥックス・ライムライトネットワークUSAメール：denver@nitrous.net
Curtis Villamizar AVICI EMail:curtis@faster-light.net
Curtis Villamizar Aviciメール：curtis@faster-light.net
Amir Birjandi Juniper Networks 2251 Corporate Park Dr., Ste. 100 Herndon, VA 20171 USA EMail: abirjandi@juniper.net
Amir Birjandi Juniper Networks 2251 Corporate Park Dr.、Ste。100 Herndon、VA 20171 USAメール：abirjandi@juniper.net
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710, January 2010.
[RFC5710] Berger、L.、Papadimitriou、D。、およびJp。Vasseur、「PatherrメッセージはMPLSおよびGMPLS LSP Reroutesをトリガーしました」、RFC 5710、2010年1月。
[RFC5711] Vasseur, JP., Swallow, G., and I. Minei, "Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages", RFC 5711, January 2010.
[RFC5711] Vasseur、JP。、Swallow、G。、およびI. Misei、「リソース予約プロトコル（RSVP）パスエラーメッセージの発信および受信時のノード動作」、RFC 5711、2010年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[RFC3270] Le Faucheur, F., 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, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC4829] de Oliveira, J., Vasseur, JP., Chen, L., and C. Scoglio, "Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering", RFC 4829, April 2007.
[RFC4829] de Oliveira、J.、Vasseur、Jp。、Chen、L。、およびC. Scoglio、「ラベルスイッチドパス（LSP）MPLSトラフィックエンジニアリングの先制ポリシー」、RFC 4829、2007年4月。
[SEC_FMWK] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[SEC_FMWK] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2009年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Matthew R. Meyer (editor) British Telecom
マシュー・R・マイヤー（編集者）英国の通信
EMail: matthew.meyer@bt.com
JP Vasseur (editor) Cisco Systems, Inc. 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France
JP Vasseur（編集者）Cisco Systems、Inc。11、Rue Camille Desmoulins Issy Les Moulineaux、92782 France
EMail: jpv@cisco.com