Network Working Group JP. Vasseur, Ed.
Request for Comments: 4736 Cisco Systems, Inc.
Category: Informational Y. Ikejiri
NTT Communications Corporation
R. Zhang
BT Infonet
November 2006
Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Loosely Routed Label Switched Path (LSP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path.
このドキュメントは緩く、ルーティングされたMPLSとGMPLS（汎用マルチプロトコルラベルスイッチング）トラフィックエンジニアリングの再最適化するためのメカニズムを定義します（TE）ラベルスイッチパス（LSP）リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）と合図をしました。この文書では、緩んでいるか、抽象ホップとして定義された次のホップを持っており、中間点のLSRが合図するためにすべてのホップに評価の再新しいパスをトリガするためにTE LSPのヘッドエンドラベルスイッチングルータ（LSR）を可能にするメカニズムを提案しています（電流経路と比較して）より良いパスが存在ヘッドエンドLSRまたはTE LSPは（なぜならTE LSPパスに必要なメンテナンスの）再最適化されなければなりません。提案されたメカニズムは、緩く経由パス次内およびドメイン間（インテリアゲートウェイプロトコル領域（IGP領域）または自律システム）パケットと非パケットTE LSPの場合に適用されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. Establishment of a Loosely Routed TE LSP ........................4
4. Reoptimization of a Loosely Routed TE LSP Path ..................6
5. Signaling Extensions ............................................7
5.1. Path Re-Evaluation Request .................................7
5.2. New Error Value Sub-Codes ..................................7
6. Mode of Operation ...............................................7
6.1. Head-End Reoptimization Control ............................7
6.2. Reoptimization Triggers ....................................8
6.3. Head-End Request versus Mid-Point Explicit
Notification Functions .....................................8
6.3.1. Head-End Request Function ...........................8
6.3.2. Mid-Point Explicit Notification ....................10
6.3.3. ERO Caching ........................................10
7. Applicability and Interoperability .............................11
8. IANA Considerations ............................................11
9. Security Considerations ........................................11
10. Acknowledgements ..............................................12
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering LSPs signaled with RSVP-TE (see [RFC3209] and [RFC3473]). A loosely routed LSP is defined as one that does not contain a full, explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no Explicit Route Object (ERO), with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR).
この文書では、トラフィックエンジニアリングのLSPは、RSVP-TE（[RFC3209]と[RFC3473]を参照）で合図を緩くルーティングされたMPLSとGMPLSの再最適化（一般化マルチプロトコルラベルスイッチング）するためのメカニズムを定義します。緩くルーティングLSPは、それが入口LSRによってシグナリングされる時のLSPの経路に沿って各LSRを識別するフル、明示的経路を含まないものとして定義されます。そのようなLSPは、少なくとも一つのルーズホップを含んEROを有する、または単純な抽象ノードではない抽象ノード（すなわち、その識別抽象ノードであるが含まEROと、明示的なルートオブジェクト（ERO）で通知され複数のLSR）。
The Traffic Engineering Working Group (TE WG) has specified a set of requirements for inter-area and inter-AS MPLS Traffic Engineering (see [RFC4105] and [RFC4216]). Both requirements documents specify the need for some mechanism providing an option for the head-end LSR to control the reoptimization process should a more optimal path exist in a downstream domain (IGP area or Autonomous System). This document defines a solution to meet this requirement and proposes two mechanisms:
トラフィックエンジニアリングワーキンググループ（WG TE）は、エリア間および相互AS MPLSトラフィックエンジニアリングのための要件のセットを指定している（[RFC4105]と[RFC4216]を参照）。文書が再最適化プロセスを制御するためのヘッドエンドLSRのためのオプションを提供するいくつかのメカニズムの必要性を指定する両方の要件は、より最適な経路は、下流のドメイン（IGP領域または自律システム）に存在しなければなりません。この文書では、この要件を満たすためのソリューションを定義し、2つのメカニズムを提案しています：
(1) The first mechanism allows a head-end LSR to trigger a new path re-evaluation on every hop that has a next hop defined as a loose hop or abstract node and get a notification from the mid-point as to whether a better path exists.
（1）第1の機構はヘッドエンドLSRが緩んホップまたは抽象ノードとして定義され、次のホップを有するすべてのホップで新しいパスの再評価をトリガし、より良いか否かの中間点からの通知を取得することができパスが存在します。
(2) The second mechanism allows a mid-point LSR to explicitly signal to the head-end LSR either that a better path exists to reach a loose/abstract hop (compared to the current path) or that the TE LSP must be reoptimized because of some maintenance required along the TE LSP path. In this case, the notification is sent by the mid-point LSR without being polled by the head-end LSR.
（2）第2のメカニズムは、中点LSRは明示的のいずれかより良いパスが（電流経路と比較して）緩い/抽象ホップに到達するために存在するか、TE LSPがあるため再最適化されなければならないことをそのヘッドエンドLSRに知らせることを可能にしますTE LSPパスに沿って必要ないくつかのメンテナンスの。この場合、通知は、ヘッドエンドLSRによってポーリングされることなく中点LSRによって送信されます。
A better path is defined as a lower cost path, where the cost is determined by the metric used to compute the path.
より良好な経路がコスト経路を計算するために使用されるメトリックによって決定される低コストの経路として定義されます。
ABR: Area Border Router.
ABR：エリア境界ルータ。
ERO: Explicit Route Object.
ERO：明示的なルートオブジェクト。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルスイッチパス。
TE LSP head-end: head/source of the TE LSP.
TE LSPのヘッドエンド：TE LSPのヘッド/ソース。
TE LSP tail-end: tail/destination of the TE LSP.
TE LSPテールエンド：TE LSPの尾/宛先。
Interior Gateway Protocol Area (IGP Area): OSPF Area or IS-IS level.
インテリアゲートウェイプロトコルエリア（IGPエリア）：OSPFエリアまたはレベルです。
Intra-area TE LSP: A TE LSP whose path does not transit across areas.
イントラ領域TE LSP：そのパス領域を横切る輸送はないTE LSP。
Inter-area TE LSP: A TE LSP whose path transits across at least two different IGP areas.
相互領域TE LSP：その経路は、少なくとも二つの異なるIGP領域を横切る遷移TE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least two different Autonomous Systems (ASes) or sub-ASes (BGP confederations).
インターAS MPLS TE LSP：そのパス遷移少なくとも二つの異なる自律システム（のAS）またはサブのAS（BGPの連合）を横切って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]に記載されているように解釈されます。
The aim of this section is purely to summarize the mechanisms involved in the establishment of a loosely routed TE LSP, as specified in [RFC3209]. The reader should see RFC 3209 for a more detailed description of these mechanisms.
このセクションの目的は、[RFC3209]で指定されるように、緩くルーティングTE LSPの確立に関与するメカニズムを要約する純粋です。読者は、これらのメカニズムのより詳細な説明については、RFC 3209を参照すべきです。
In the context of this document, a loosely routed LSP is defined as one that does not contain a full, explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no ERO, with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR). As specified in [RFC3209], loose hops are listed in the ERO object of the RSVP Path message with the L flag of the IPv4 or the IPv6 prefix sub-object set.
本文書の文脈において、緩くルーティングLSPは、それが入口LSRによってシグナリングされる時のLSPの経路に沿って各LSRを識別するフル、明示的経路を含まないものとして定義されます。そのようなLSPは、少なくとも一つのルーズホップを含んEROでないEROでシグナリングされるか、または単純な抽象ノード（つまり、複数のLSRを識別する抽象ノードである）ではない抽象ノードを含むEROと。 [RFC3209]で指定されるように、ルーズホップは、IPv4またはIPv6プレフィックスサブオブジェクトセットのLフラグとRSVP PathメッセージのEROオブジェクトに記載されています。
Each LSR along the path whose next hop is specified as a loose hop or a non-specific abstract node triggers a path computation (also referred to as an ERO expansion), before forwarding the RSVP Path message downstream. The computed path may be either partial (up to the next loose hop) or complete (set of strict hops up to the TE LSP destination).
ネクストホップルーズホップまたは非特定の抽象ノードとして指定されている（また、ERO拡張と称する）経路計算をトリガし、下流RSVP Pathメッセージを転送する前に経路に沿って各LSR。計算された経路は、（次のルーズホップまで）部分的または完全な（TE LSP先まで厳密ホップのセット）のいずれであってもよいです。
Note that although the examples in the rest of this document are provided in the context of MPLS inter-area TE, the proposed mechanism applies equally to loosely routed paths within a single routing domain and across multiple Autonomous Systems. The examples below are provided with OSPF as the IGP, but the described set of mechanisms similarly apply to IS-IS.
この文書の残りの例は、MPLSインターエリアTEに関連して提供されているが、提案された機構は、単一のルーティングドメイン内で、複数の自律システム間で緩くルーティングパスに等しく適用されることに留意されたいです。以下の実施例は、IGPとしてOSPFを設けたが、機構の説明セットも同様にIS-ISにも適用されます。
An example of an explicit loosely routed TE LSP signaling follows.
明示的に緩くルーティングされたTE LSPシグナリングの例は次の通りです。
<---area 1--><-area 0--><-area 2->
R1---R2----R3---R6 R8---R10
| | | / | \ |
| | | / | \ |
| | | / | \|
R4---------R5---R7----R9---R11
Assumptions
仮定
- R3, R5, R8, and R9 are ABRs.
- R3、R5、R8、及びR9はのABRです。
- The path of an inter-area TE LSP T1 from R1 (head-end LSR) to R11 (tail-end LSR) is defined on R1 as the following loosely routed path: R1-R3(loose)-R8(loose)-R11(loose). R3, R8, and R11 are defined as loose hops.
- R11（テールエンドLSR）へR1（ヘッドエンドLSR）から相互領域TE LSP T1の経路は、以下緩く経由パスとしてR1上に定義される：R1-R3（ルーズ）-R 8（緩いです） - R11（緩いです）。 R3、R8、及びR11は、ルーズホップとして定義されます。
Step 1: R1 determines that the next hop (R3) is a loose hop (not directly connected to R1) and then performs an ERO expansion operation to reach the next loose hops R3. The new ERO becomes: R2(S)-R3(S)-R8(L)-R11(L), where S is a strict hop (L=0) and L is a loose hop (L=1).
ステップ1：R1は、ネクストホップ（R3）がルーズホップであると判断する（直接R1に接続されていない）、次いで、次のルーズホップR3に到達するERO伸張動作を行います。新しいEROになる：R2（S）-R 3 Sは、厳密ホップ（L = 0）、Lである（S）-R 8（L）-R 11（L）は、ルーズホップ（L = 1）です。
The R1-R2-R3 path satisfies T1's set of constraints.
R1-R2-R3のパスは、制約のT1のセットを満たします。
Step 2: The RSVP Path message is then forwarded by R1 following the path specified in the ERO object and reaches R3 with the following content: R8(L)-R11(L).
ステップ2：RSVP Pathメッセージは、その後、EROオブジェクトで指定されたパス以下R1によって転送し、次のコンテンツとR3に到達する：R8（L）-R11（L）。
Step 3: R3 determines that the next hop (R8) is a loose hop (not directly connected to R3) and then performs an ERO expansion operation to reach the next loose hops R8. The new ERO becomes: R6(S)-R7(S)-R8(S)-R11(L).
ステップ3：R3は、ネクストホップ（R8）がルーズホップであると判断する（直接R3に接続されていない）、次いで、次のルーズホップR8に到達するERO伸張動作を行います。新しいEROは次のようになります。R6（S）-R7（S）-R 8（S）-R 11（L）。
Note: In this example, the assumption is made that the path is computed on a per-loose-hop basis, also referred to as a partial route computation. Note that other path computation techniques may result in complete paths (set of strict hops up to the final destination).
注：この例では、仮定は、部分経路計算と呼ばれる、パスごとのルーズホップに基づいて計算されることが行われます。他の経路計算技術は、完全なパス（最終目的地まで厳密ホップのセット）をもたらし得ることに留意されたいです。
Step 4: The same procedure is repeated by R8 to reach T1's destination (R11).
ステップ4：同じ手順T1の宛先（R11）に達するR8によって繰り返されます。
Once a loosely routed, explicit TE LSP is set up, it is maintained through normal RSVP procedures. During the TE LSP lifetime, a more optimal path might appear between an LSR and its next loose hop (for the sake of illustration, suppose that in the example above a link between R6 and R8 is added or restored that provides a preferable path between R3 and R8 (R3-R6-R8) than the existing R3-R6-R7-R8 path). Since a preferable (e.g., shorter) path might not be visible from the head-end LSR by means of the IGP if the head-end LSR does not belong to the same IGP area where the associated topology change occurred, the head-end cannot make use of this shorter path (and reroute the LSP using a make-before-break technique as described in [RFC3209]) when appropriate. Thus, a new mechanism specified in this document is required to detect the existence of such a preferable path and to notify the head-end LSR accordingly.
緩くルーティングされ、明示的なTE LSPを設定すると、それは通常のRSVPの手順により維持されています。 TE LSPの寿命の間、より最適な経路は、（説明のために、R6とR8の間のリンク上の例ではR3との間の好ましい経路を提供する追加または復元されると仮定LSRとその次のルーズホップの間に現れるかもしれません既存R3-R6-R7-R8経路よりR8（R3-R6-R8））。ヘッドエンドLSRは、ヘッドエンドができない、関連したトポロジ変更が発生した同じIGP領域に属していない場合が望ましい（例えば、短い）パスは、IGPによってヘッドエンドLSRから見えないかもしれないのでこの短いパスを使用すること（及び[RFC3209]に記載されているようにメーク・ビフォア・ブレーク技術を使用してLSPを再ルーティング）適切な場合。したがって、この文書で指定された新しい機構は、好ましい経路の存在を検出し、それに応じてヘッドエンドLSRに通知する必要があります。
This document defines a mechanism that allows
この文書では、可能にするメカニズムを定義します
- a head-end LSR to trigger on every LSR whose next hop is a loose hop or an abstract node the re-evaluation of the current path in order to detect a potentially more optimal path; and
- その次のホップルーズホップまたは抽象ノード潜在的に、より最適な経路を検出するために電流経路の再評価であるすべてのLSRにトリガするヘッドエンドLSR。そして
- a mid-point LSR whose next hop is a loose-hop or an abstract node to signal (using a new Error Value sub-code carried in a RSVP PathErr message) to the head-end LSR that a preferable path exists (a path with a lower cost, where the cost definition is determined by some metric).
- そのネクストホップ中点LSRはルーズホップまたは好ましい経路が存在することをヘッドエンドLSRに（RSVP用のPathErrメッセージで運ばれる新しいエラー値のサブコードを使用して）シグナリングする抽象ノード（パスは）コストの定義が何らかのメトリックによって決定される低コスト、を有します。
Once the head-end LSR has been notified of the existence of such a preferable path, it can decide (depending on the TE LSP characteristics) whether to perform a TE LSP graceful reoptimization such as the "make-before-break" procedure.
ヘッドエンドLSRは、好ましい経路の存在を通知されたならば、そのような「メークビフォアブレーク」手順としてTE LSP優雅な再最適化を実行するかどうか（TE LSPの特性に依存して）決定することができます。
There is another scenario whereby notifying the head-end LSR of the existence of a better path is desirable: if the current path is about to fail due to some (link or node) required maintenance.
メンテナンスが必要な電流経路が何らかの（リンクまたはノード）に失敗しようとしている場合：良好パスの存在のヘッドエンドLSRに通知することにより、別のシナリオが望ましいがあります。
This mechanism allows the head-end LSR to reoptimize a TE LSP by making use of the non-disruptive make-before-break procedure if and only if a preferable path exists and if such a reoptimization is desired.
この機構は、ヘッドエンドLSRの場合にのみ好ましい経路が存在する無停止メーク・ビフォア・ブレーク手順を使用することによって、そのような再最適化が望まれる場合TE LSPを再最適化することを可能にします。
A new flag in the SESSION ATTRIBUTE object and new Error Value sub-codes in the ERROR SPEC object are proposed in this document.
セッション属性オブジェクトおよびエラーSPECオブジェクト内の新しいエラー値のサブコードに新しいフラグは、この文書で提案されています。
The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 7) is defined:
SESSION_ATTRIBUTE物（C-1型及び7）の次の新しいフラグが定義されます。
Path re-evaluation request: 0x20
パス再評価要求：0x20の
This flag indicates that a path re-evaluation (of the current path in use) is requested. Note that this does not trigger any LSP Reroute but instead just signals a request to evaluate whether a preferable path exists.
このフラグは、（現在使用中のパスの）経路の再評価が要求されていることを示しています。これは、任意のLSP再ルーティングをトリガする代わりに、単に好ましい経路が存在するかどうかを評価するための要求を通知しないことに留意されたいです。
Note: In case of link bundling, for instance, although the resulting ERO might be identical, this might give the opportunity for a mid-point LSR to locally select another link within a bundle. However, strictly speaking, the ERO has not changed.
注：インスタンスのリンクバンドリングの場合には、得られたEROは同じかもしれないが、これは、局所的に、バンドル内の別のリンクを選択するために、中間点LSRのための機会を与えるかもしれません。しかし、厳密に言えば、EROが変更されていません。
As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object corresponds to a Notify Error.
[RFC3209]で定義されるように、誤差SPECオブジェクト内のエラーコード25は、エラー通知に対応しています。
This document adds three new Error Value sub-codes:
この文書では、3の新しいエラー値サブコードを追加します。
6 Preferable path exists
6好ましい経路が存在します
7 Local link maintenance required
7ローカルリンクのメンテナンスに必要な
8 Local node maintenance required
8ローカルノードのメンテナンスに必要な
The details about the local maintenance required modes are in Section 6.3.2.
地元のメンテナンスに必要なモードの詳細は、6.3.2項です。
The notification process of a preferable path (shorter path or new path due to some maintenance required on the current path) is by nature de-correlated from the reoptimization operation. In other words, the location where a potentially preferable path is discovered does not have to be where the TE LSP is actually reoptimized. This document applies to the context of a head-end LSR reoptimization.
好ましい経路（これは電流経路上に必要ないくつかのメンテナンスのより短い経路または新規経路）の通知処理は、自然脱相関再最適化操作からによるものです。換言すれば、潜在的に好ましい経路が発見された場所は、TE LSPが実際に再最適化される必要はありません。この文書では、ヘッドエンドLSRの再最適化のコンテキストに適用されます。
There are several possible reoptimization triggers:
いくつかの可能な再最適化のトリガーがあります。
- Timer-based: A reoptimization is triggered (process evaluating whether a more optimal path can be found) when a configurable timer expires.
- タイマベース：設定可能なタイマーが満了したときに再最適化は、（より最適な経路を見つけることができるかどうかを評価する工程）トリガされます。
- Event-driven: A reoptimization is triggered when a particular network event occurs (such as a "Link-UP" event).
- イベント駆動型：特定のネットワークイベント（例えば、「リンクアップ」イベントとして）発生したときに再最適化がトリガされます。
- Operator-driven: A reoptimization is manually triggered by the Operator.
- オペレータ主導：再最適化を手動操作によってトリガされます。
It is RECOMMENDED that an implementation supporting the extensions proposed in this document support the aforementioned modes as path re-evaluation triggers.
パスの再評価をトリガーとして、この文書で提案された拡張をサポートする実装は、前述のモードをサポートすることが推奨されます。
This document defines two functions:
この文書では、2つの機能を定義しています。
1) "Head-end requesting function": The request for a new path evaluation of a loosely routed TE LSP is requested by the head-end LSR.
1）「ヘッドエンド機能を要求する」：緩くルーティングされたTE LSPの新しいパスの評価のための要求は、ヘッドエンドLSRによって要求されています。
2) "Mid-point explicit notification function": Having determined that a preferable path (other than the current path) exists or having the need to perform a link/node local maintenance, a mid-point LSR explicitly notifies the head-end LSR, which will in turn decide whether to perform a reoptimization.
2）「中間点の明示的な通知機能」：好ましい経路（電流経路以外）が存在するか、リンク/ノードのローカル・メンテナンスを実行する必要性を有し、中間点LSRが明示的にヘッドエンドLSRに通知すると判断しました、順番に再最適化を実行するかどうかを決定するであろう。
When a timer-based reoptimization is triggered on the head-end LSR or the operator manually requests a reoptimization, the head-end LSR immediately sends an RSVP Path message with the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object set. This bit is then cleared in subsequent RSVP path messages sent downstream. In order to handle the case of a lost Path message, the solution consists of relying on the reliable messaging mechanism described in [RFC2961].
タイマーベースの再最適化は、ヘッドエンドLSRでトリガまたはオペレータが手動で再最適化を要求されたときに、ヘッドエンドLSRは直ちにセッション属性オブジェクトセットの「パス再評価要求」ビットでRSVP Pathメッセージを送信します。 。このビットは、その後、下流送信され、その後のRSVPパスメッセージでクリアされます。失われたPathメッセージの場合を扱うために、溶液は[RFC2961]に記載の信頼性のあるメッセージングメカニズムに頼るから成ります。
Upon receiving a Path message with the "Path re-evaluation request" bit set, every LSR for which the next abstract node contained in the ERO is defined as a loose hop/abstract node performs the following set of actions:
「パス再評価要求」ビットがセットされたPathメッセージを受信すると、EROに含まれる次の抽象ノードはルーズホップ/アブストラクトノードとして定義されているすべてのLSRは、アクションの次のセットを実行します。
A path re-evaluation is triggered, and the newly computed path is compared to the existing path:
経路の再評価がトリガされ、新たに計算された経路は、既存のパスと比較されます。
- If a preferable path can be found, the LSR performing the path re-evaluation MUST immediately send an RSVP PathErr to the head-end LSR (Error code 25 (Notify), Error sub-code=6 (better path exists)). At this point, the LSR MAY decide not to propagate this bit in subsequent RSVP Path messages sent downstream for the re-evaluated TE LSP; this mode is the RECOMMENDED mode for the reasons described below.
- 好適な経路を見つけることができる場合、再評価パスを実行するLSRは、直ちにヘッドエンドLSR（エラーコード25（通知）、エラーサブコード= 6（より良いパスが存在する））へのRSVPのPathErrを送らなければなりません。この時点で、LSRは再評価さTE LSPのために下流送信され、その後のRSVPのPathメッセージでこのビットを伝播しないことを決定することができます。このモードでは、以下の理由のための推奨モードです。
The sending of an RSVP PathErr Notify message "Preferable path exists" to the head-end LSR will notify the head-end LSR of the existence of a preferable path (e.g., in a downstream area/AS or in another location within a single domain). Therefore, triggering additional path re-evaluations on downstream nodes is unnecessary. The only motivation to forward subsequent RSVP Path messages with the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object set would be to trigger path re-evaluation on downstream nodes that could in turn cache some potentially better paths downstream, with the objective to reduce the signaling setup delay, should a reoptimization be performed by the head-end LSR.
RSVP用のPathErrの送信メッセージLSR（例えば、下流領域でAS /又は単一ドメイン内の別の場所に好ましい経路の存在のヘッドエンドLSRに通知するヘッドエンドに「好ましい経路が存在する」通知）。したがって、下流ノードに追加のパスの再評価をトリガすることは不要です。唯一の動機は「パス再評価要求」と後続のRSVP Pathメッセージを転送するためにセッション属性オブジェクトセットのビットは、ダウンストリームノードで経路の再評価をトリガするであろうという可能性を持つ、いくつかの潜在的により良い経路下流ターンキャッシュにシグナリングセットアップ遅延を減少させる目的、再最適化は、ヘッドエンドLSRによって実行されるべきです。
- If no preferable path can be found, the recommended mode is for an LSR to relay the request (by setting the "Path re-evaluation" bit of the SESSION-ATTRIBUTE object in RSVP path message sent downstream).
- いかなる好適パスが見つからない場合、推奨されるモードは、LSRが（ダウンストリーム送信されたRSVPの経路メッセージにセッション属性オブジェクトの「パスの再評価」ビットをセットすることによって）要求を中継するためのものです。
Note that, by preferable path, we mean a path with a lower cost.
好ましいパスによって、我々は低コストでパスを意味することに注意してください。
If the RSVP Path message with the "Path re-evaluation request" bit set is lost, then the next request will be sent when the next reoptimization trigger will occur on the head-end LSR. The solution to handle RSVP reliable messaging has been defined in [RFC2961].
「パスの再評価要求」ビットがセットされたRSVP Pathメッセージが失われた場合、次の再最適化トリガがヘッドエンドLSRに発生しますと、その後、次のリクエストが送信されます。 RSVP信頼性の高いメッセージングを処理するための解決策は、[RFC2961]で定義されています。
The network administrator may decide to establish some local policy specifying to ignore such request or not to consider those requests more frequently than at a certain rate.
ネットワーク管理者は、より頻繁に一定の割合でよりこれらの要求を考慮し、このような要求を無視するかどうかを指定するいくつかのローカルポリシーを確立することを決定することができます。
The proposed mechanism does not make any assumption of the path computation method performed by the ERO expansion process.
提案されたメカニズムは、ERO拡張処理によって実行される経路計算方法のいずれかの仮定を行いません。
By contrast with the head-end request function, in this case, a mid-point LSR whose next hop is a loose hop or an abstract node can locally trigger a path re-evaluation when a configurable timer expires, some specific events occur (e.g., link-up event), or the user explicitly requests it. If a preferable path is found, the LSR sends an RSVP PathErr to the head-end LSR (Error code 25 (Notify), Error sub-code=6 ("preferable path exists").
構成タイマが満了したときにヘッドエンド要求機能とは対照的に、この場合には、そのネクストホップ中点LSRが緩んホップまたは抽象ノードが局所的に再評価パスをトリガすることができるされ、いくつかの特定のイベントが発生する（例えば、リンクアップイベントが）、またはユーザーが明示的に要求します。好ましい経路が見つかった場合、LSRは、ヘッドエンドLSR（エラーコード25（通知）、エラーサブコード= 6（「好ましい経路が存在する」）へのRSVPのPathErrを送信します。
There is another circumstance whereby any mid-point LSR MAY send an RSVP PathErr message with the objective for the TE LSP to be rerouted by its head-end LSR: when a link or a node will go down for local maintenance reasons. In this case, the LSR where a local maintenance must be performed is responsible for sending an RSVP PathErr message with Error code 25 and Error sub-code=7 or 8, depending on the affected network element (link or node). Then the first upstream node that has performed the ERO expansion MUST perform the following set of actions:
リンクまたはノードがローカル保守的な理由のために下がるだろうとき：任意の中間点LSRは、そのヘッドエンドLSRによって再ルーティングされるTE LSPのための目的で、RSVPのPathErrメッセージを送信することができることにより、別の状況があります。この場合、ローカルメンテナンスを行わなければならないLSRは、影響を受けるネットワーク要素（リンク又はノード）に応じて、エラー・コード25およびエラーサブコード= 7または8とのRSVPのPathErrメッセージを送信する責任があります。次いでERO拡張を行った最初の上流ノードはアクションの次のセットを実行する必要があります。
- The link (sub-code=7) or the node (sub-code=8) MUST be locally registered for further reference (the TE database must be updated).
- リンク（サブコード= 7）またはノード（サブコード= 8）は、局所的に（TEデータベースが更新されなければならない）をさらに参照のために登録しなければなりません。
- The RSVP PathErr message MUST be immediately forwarded upstream to the head-end LSR. Note that in the case of TE LSP spanning multiple administrative domains, it may be desirable for the boundary LSR to modify the RSVP PathErr message and insert its own address for confidentiality.
- RSVP用のPathErrメッセージは直ちにヘッドエンドLSRの上流に転送されなければなりません。境界LSRは、RSVPののPathErrメッセージを変更し、機密性のために自身のアドレスを挿入するための複数の管理ドメインにまたがるTE LSPの場合、それは望ましいかもしれないことに留意されたいです。
Upon receiving an RSVP PathErr message with Error code 25 and Error sub-code 7 or 8, the head-end LSR SHOULD perform a TE LSP reoptimization.
エラーコード25およびエラーサブコード7または8でのRSVPのPathErrメッセージを受信すると、ヘッドエンドLSRは、TE LSPの再最適化を実行する必要があります。
Note that the two functions (head-end and mid-point driven) are not exclusive of each other: both the timer and event-driven reoptimization triggers can be implemented on the head-end or on any mid-point LSR with a potentially different timer value for the timer-driven reoptimization case.
二つの機能（ヘッドエンドと中間点が駆動される）ことに留意されたい互いに排他的ではなく、タイマ、イベント・ドリブン再最適化トリガの両方が、潜在的に異なるとヘッドエンドまたは任意の中間点LSR上に実装することができますタイマー駆動型の再最適化のケースのためのタイマ値。
A head-end LSR MAY decide upon receiving an explicit mid-point notification to delay its next path re-evaluation request.
ヘッドエンドLSRは、その次のパスを再評価要求を遅らせるために、明示的な中間点の通知を受けて判断してもよいです。
Once a mid-point LSR has determined that a preferable path exists (after a reoptimization request has been received by the head-end LSR or the reoptimization timer on the mid-point has expired), the more optimal path MAY be cached on the mid-point LSR for a limited amount of time to avoid having to recompute a path once the head-LSR performs a make-before-break. This mode is optional. A default value of 5 seconds for the caching timer is suggested.
中点たらLSRは、（再最適化要求がヘッドエンドLSRによって受信されたか、または中間点に再最適化タイマが満了した後に）好ましい経路が存在し、より最適な経路は、中間にキャッシュすることができることを決定しましたヘッド-LSRは、メイク・ビフォア・ブレークを行い、いったんパスを再計算することを避けるために、時間の限られた量のためのLSRを-POINT。このモードはオプションです。キャッシュタイマーのための5秒のデフォルト値が推奨されます。
The procedures described in this document are entirely optional within an MPLS or GMPLS network. Implementations that do not support the procedures described in this document will interoperate seamlessly with those that do. Further, an implementation that does not support the procedures described in this document will not be impacted or implicated by a neighboring implementation that does implement the procedures.
この文書に記載された手順は、MPLS又はGMPLSネットワーク内に完全に任意です。この文書に記載されている手順をサポートしない実装はないものとシームレスに相互運用します。さらに、本文書に記載されている手順をサポートしていない実装では、手順を実装し、隣接する実装によって影響または関与しないであろう。
An ingress implementation that chooses not to support the procedures described in this document may still achieve re-optimization by periodically issuing a speculative make-before-break replacement of an LSP without trying to discovery whether a more optimal path is available in a downstream domain. Such a procedure would not be in conflict with any mechanisms already documented in [RFC3209] and [RFC3473].
このドキュメントで説明する手順はまだ定期的に、より最適な経路は、下流のドメインで利用可能であるかどうかを発見しようとせずにLSPの投機メイク・ビフォア・ブレーク交換を発行することにより、再最適化を達成することができるサポートしないことを選択した入口実装。そのような手順は、すでに[RFC3209]及び[RFC3473]に記載の任意のメカニズムと矛盾しないであろう。
An LSR not supporting the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object SHALL forward it unmodified.
LSRは、修飾されていない、それを送付するSESSION-ATTRIBUTEオブジェクトの「パスの再評価要求」ビットをサポートしていません。
A head-end LSR not supporting an RSVP PathErr with Error code 25 message and Error sub-code = 6, 7, or 8 MUST just silently ignore such an RSVP PathErr message.
ヘッドエンドLSRは、エラーコード25メッセージおよびエラーサブコードとのRSVPのPathErrをサポートしていない= 6、7、または8は単に黙っ例えばRSVP用のPathErrメッセージを無視しなければなりません。
IANA assigned three new error sub-code values for the RSVP PathErr Notify message (Error code=25):
IANAは、メッセージ（エラーコード= 25）通知のPathErr RSVPのための3つの新しいエラーサブコード値が割り当てられ。
6 Preferable path exists
6好ましい経路が存在します
7 Local link maintenance required
7ローカルリンクのメンテナンスに必要な
8 Local node maintenance required
8ローカルノードのメンテナンスに必要な
This document defines a mechanism for a mid-point LSR to notify the head-end LSR of the existence of a preferable path or the need to reroute the TE LSP for maintenance purposes. Hence, in the case of a TE LSP spanning multiple administrative domains, it may be desirable for a boundary LSR to modify the RSVP PathErr message (Code 25, Error sub-code = 6, 7, or 8) so as to preserve confidentiality across domains. Furthermore, a head-end LSR may decide to ignore explicit notification coming from a mid-point residing in another domain. Similarly, an LSR may decide to ignore (or to accept up to a pre-defined rate) path re-evaluation requests originated by a head-end LSR of another domain.
この文書では、好ましい経路または保守目的のためにTE LSPを再ルーティングする必要の有無のヘッドエンドLSRに通知する中点LSRのためのメカニズムを定義します。したがって、複数の管理ドメインにまたがるTE LSPの場合、それは、RSVPのPathErrメッセージ（コード25、エラーサブコード= 6、7、または8）の両端の機密性を保持するように変更する境界LSRのために望ましいかもしれませんドメイン。さらに、ヘッドエンドLSRは別のドメインに存在する中間点からの明示的な通知を無視するように決定することができます。同様に、LSRは無視する（または事前に定義された速度まで受け入れるように）再評価の別のドメインのヘッドエンドLSRによって発信要求経路を決定することができます。
The authors would like to thank Carol Iturralde, Miya Kohno, Francois Le Faucheur, Philip Matthews, Jim Gibson, Jean-Louis Le Roux, Kenji Kumaki, Anca Zafir, and Dimitri Papadimitriou for their useful comments. A special thanks to Adrian Farrel for his very valuable inputs.
作者は彼らの役に立つコメントをキャロルIturralde、宮河野、フランソワ・ルFaucheur、フィリップ・マシューズ、ジム・ギブソン、ジャン=ルイ・ル・ルー、健二熊木、ANCA Zafir、およびディミトリPapadimitriouに感謝したいと思います。彼の非常に貴重な入力のためのエードリアンファレルに感謝します。
[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月。
[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月。
[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。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]張、R.及びJ.-P. Vasseur、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
Authors' Addresses
著者のアドレス
JP Vasseur (Editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（編集）シスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-8019 Japan
ゆいち いけじり んっｔ こっむにかちおんｓ こｒぽらちおん １ー１ー６、 うちさいわいーちょ、 ちよだーく ときょ、 １００ー８０１９ じゃぱん
EMail: y.ikejiri@ntt.com
メールアドレス：y.ikejiri@ntt.com
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンド・チャンBTインフォネット2160 E.グランドアベニューエル・セグンド、CA 90025 USA
EMail: raymond_zhang@bt.infonet.com
メールアドレス：raymond_zhang@bt.infonet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。