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
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変位をサポートして定義されました。リルート要求通知の利用は、より優雅に先取りTE LSPの再ルーティングプロセスを軽減します。短時間ソフトプリエンプションは（必ずしもトラフィックレベルが）TE LSP（S）までプロビジョニング下効果にある再ルーティングすることができ、予約が活性化されます。このため、この機能は主に、排他的ではないが、差別化サービスおよびトラフィックエンジニアリング機能を備えた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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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のLSP。代替なしに、ネットワークオペレータは、この制限を受け入れるか、一つだけ先取り優先順位を使用して、または無効な帯域予約値を使用して機能を削除します。プリエンプションが侵入し、ネットワークの安定性レベルの高いレベルを維持しているときに当然イングレスラベルエッジルータ（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を警告し、一時的なコントロールプレーン下プロビジョニングを可能にするために追加のシグナリングとメンテナンス機構の使用を定義する（メークビフォアブレーク）イングレスLERによります。トンネルが再ルーティングされている期間中に、リンク容量は、プリエンプションが開始され、潜在的に上流の他のソフトプリエンプションが発生した可能性がある経路に沿って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.
先取りのポイント - のいずれかのハードプリエンプトまたは下プロビジョニング強制とソフトプリエンプションを通知されたプロビジョニングレベルを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をティアダウンTE LSPプリエンプションの唯一の方法をサポートするように定義されました。この単純だが、急激なプロセスはほぼ保証は短時間だけあればRSVPパスエラーメッセージが到達したとイングレスLERによって処理され、新しいデータパスが確立されるまでトラフィックは、破棄されます先取り。 RSVPパスのエラーメッセージ内で搬送エラーコードとエラー値は、[RFC5711]に記載されていプリエンプションアクションを報告します。そのようなプリエンプションはまた、[RFC5711]に致命的なエラーと呼ばれることに留意されたいです。実際のリソースの競合の場合、これは役に立つかもしれません。しかし、プリエンプションは単なる予約の競合によってトリガすることができる、と予約は今までのデータプレーンの競合を反映していないかもしれません。結果は、プリエンプションを促進する条件が存在し、ハードプリエンプションは、デフォルトの動作である場合に十分な帯域幅がプリエンプトTE LSPと先取りTE LSP（単数または複数）の両方に存在する場合、下位優先プリエンプトトラフィックを無駄に廃棄することができるということです。
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.
ハードプリエンプションは非のDiffserv対応のアーキテクチャに数値的により低い先取り優先順位のトラフィックを保護する必要かもしれませんが、Diffservの対応のアーキテクチャでは、1マーキング以来、最も大切なトラフィックのための好みを強制するためにプリエンプション時に、もっぱら頼る必要はありませんそしてキューイング規律はすでに、これらの目的のために整列されなければなりません。また、偶数非diffserv対応ネットワークにおいて、ルールサイジングTE LSPに応じて、予約の競合を正確にデータプレーン輻輳の可能性を反映しないかもしれない（すべてのLSPが二重それらの観察されたトラフィック・レベルで大きさを想像）。
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]は、中点がTE LSP要求（ - 再ルーティングエラーコード= 34）を再ルーティング報告することを可能にする新たなリルート固有のエラーコードを定義して指定します。この文書では、ソフト先取りした場合の新しいエラー値サブコードを指定します。
Error-value Meaning Reference 1 Reroute Request Soft Preemption This document
エラー値の意味リファレンス1リルート要求ソフトプリエンプションこの文書では、
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（「再ルーティング」）値= 1（「リルート要求ソフトプリエンプション」）との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
R0 - > R1 R1 < - R2 \ | W W R 4 R 5
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ギガビット/秒です。
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メガビット/秒です。
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の各回路10のIGPメトリックを有しており、IGPメトリックは、CSPFによって使用されます。
o Two TE tunnels are defined:
O二つのTEトンネルが定義されています。
* LSP1: 155 Mbit/s, setup/hold priority 0 tunnel, path R0-R1-R5.
* LSP1：155メガビット/秒、セットアップ/ホールド優先0トンネル、経路R0-R1-R5。
* LSP2: 155 Mbit/s, setup/hold priority 7 tunnel, path R2-R1-R4.
* LSP2：155メガビット/秒、セットアップ/ホールド優先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は、障害を検出し、TE LSPを持っているすべてのヘッドエンドのLSR（上記の例ではR0）失敗したリンクをトラバースに更新IGP LSA / LSPとパスエラーメッセージを送信します。通知のいずれかの形態は、第1のヘッドエンドのLSRに到達することができます。リンク障害通知を受信すると、R0に沿ってTE LSP制約を満たす利用可能な最短経路をLSP1の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用R1のローカル帯域幅会計がゼロになる、（LSP2のための即時のトラフィックの中断につながる）ハードプリエンプションのように先取するとLSP2のためのPathTearメッセージを送信すると、エラーコード「リルート」と値での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（S）のセットを必要と通知されたとき、ノードは、その必要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はプリエンプトTE LSPのための即時のトラフィックの中断をもたらす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.
対照的に、ソフトプリエンプションと動作モードは以下の通りである：プリエンプトTE LSPを占め先取りノードのローカル帯域幅がゼロにされると、エラーコード「リルート」、およびそのTEに対するエラー値「リルート要求ソフトプリエンプション」との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.
先取りノードは、直ちに各ソフトプリエンプトTE LSPのための「リクエストソフトプリエンプションを再ルーティング」エラーコード「リルート」と誤差値との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.
アンダープロビジョニング帯域幅が永遠に続くような状況を防ぐために、（「ソフト先取りタイマー」という名前の）ローカルタイマーはソフトプリエンプション時にプリエンプションノード上で起動する必要があります。このタイマーが期限切れになった場合、先取りノードは、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]で定義されたMESSAGE-IDの拡張が利用可能であり、有効にすると、エラーコード「リルート」とエラー値との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のセットアップ優先度よりも数値的に高い保持優先度を持っているのTE LSPを先取りするかもしれません。同じ優先順位内で、最初はクリアセッション属性オブジェクトの「ソフトプリエンプション所望の」ビット、ハードプリエンプタブルと考えられる、すなわち、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
先取り中点でプリエンプトTE LSPの選択：数値的に低い優先度TE LSPがシグナリングされる数値より高い優先順位のLSPのセットのプリエンプションを要求、プリエンプションが発生しているノードは、TEのセットに決定を行う必要がありますプリエンプションの候補であるLSP（複数可）。 （例えば、[RFC4829]を参照）、この決定は、ローカル決定であり、様々なアルゴリズムは、目的に応じて、使用することができます。すでに述べたように、ソフト先取りTEのLSPのは、それぞれのヘッドエンドで再ルーティングされながら、ソフトプリエンプションは、下のプロビジョニング状態の一時的なリンクの原因となります
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.
LSR。局所的に別のノードによってフラグが立てられなくソフトプリエンプションのために依然として利用可能であるソフトプリエンプタブルTE LSPの帯域幅が存在する場合には、この下プロビジョニング曝露を低減するために、ソフト先取りのLSRは、最初のチェックしてもよいです。十分なオーバーラップ帯域幅が存在する場合、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.
このような容認できないリンクの混雑のような特定の状況下では、ノードは、（致命的なパスエラーメッセージ、PathTear、そしてたResvTearいずれかまたは「Path_State_Removed」フラグが設定されたパスのエラーメッセージを送信することによって）TE LSPを先取りハードすることを決定することができる場合であってもそのヘッドエンド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).
エラーコード「リルート」とのPathErrメッセージとエラー値「リルートソフトプリエンプションを要求」を受信すると、最初のCSPFを実行することによって、例えば、（新たな経路を計算する前に、TE-DBの作業用コピーを更新することができるヘッドエンドLSR ）新しい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.
アンダープロビジョニング帯域幅が永遠に続くような状況を防ぐために、前述したように、ローカルタイマー（ソフトプリエンプションタイマー）は、ソフトプリエンプション時にプリエンプションノード上で起動する必要があります。このタイマーの期限が切れると、ソフト先取りTE LSPは、ハード致命的なパスのエラーメッセージ、PathTearメッセージ、およびたResvTearメッセージや「Path_State_Removed」フラグが設定されているのPathErrメッセージのいずれかを送信することにより、プリエンプトされるべき。このタイマーは設定可能であるべきであり、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
PPEND（プリエンプション出願中）の状態で現在のLSPと帯域幅のO一覧
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.
観察EROホップあたりO累積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
ビットフラグ名リファレンス0x40のソフトプリエンプションは、この文書を希望します
[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は、要求を再ルーティング報告することを可能にする新たなリルート固有のエラーコードを定義します。この文書では、ソフトプリエンプションの場合のための新しいエラーサブコードの値を指定します。
Error-value Meaning Reference 1 Reroute Request Soft Preemption This document
エラー値の意味リファレンス1リルート要求ソフトプリエンプションこの文書では、
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.
作者は彼らの貴重なコメントのためにキャロルIturralde、デイブ・クーパー、ロア・アンダーソン、Arthi Ayyangar、伊那Minei、ジョージくん、エードリアンファレル、およびムスタファAissaouiに感謝したいと思います。
Denver Maddux Limelight Networks USA EMail: denver@nitrous.net
デンバーマダックスライムライト・ネットワークスUSA Eメール：denver@nitrous.net
Curtis Villamizar AVICI EMail:curtis@faster-light.net
カーティスVillamizar AVICI Eメール：curtis@faster-light.net
Amir Birjandi Juniper Networks 2251 Corporate Park Dr., Ste. 100 Herndon, VA 20171 USA EMail: abirjandi@juniper.net
アミールBirjandiジュニパーネットワークスの2251年コーポレートパーク博士は、マリー。 100ハーンドン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、Papadimitriou、D.、およびJP。 Vasseur、 "たPathErrメッセージがトリガMPLSとGMPLS LSP再ルーティング"、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。、ツバメ、G.、およびI. Minei、 "発信時にノードの動作と受信リソース予約プロトコル（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]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（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]デ・オリベイラ、J.、Vasseur、JP。、陳、L.、およびC. Scoglioの、 "MPLSトラフィックエンジニアリングのためのラベルスイッチパス（LSP）プリエンプションポリシー"、RFC 4829、2007年4月。
[SEC_FMWK] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[SEC_FMWK]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2009年10月に作業。
Authors' Addresses
著者のアドレス
Matthew R. Meyer (editor) British Telecom
マシュー・R.マイヤー（編集者）ブリティッシュテレコム
EMail: matthew.meyer@bt.com
メールアドレス：matthew.meyer@bt.com
JP Vasseur (editor) Cisco Systems, Inc. 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France
JP Vasseur（エディタ）は、シスコシステムズ社11、ルーカミーユ・デムーラン、イッシー・レ・ムリノー、フランス92782
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com