[要約] RFC 4736は、MPLS Traffic Engineering (TE)の再最適化に関するもので、Loosely Routed Label Switched Path (LSP)の改善を目的としています。このRFCは、MPLSネットワークのトラフィックエンジニアリングにおけるLSPの最適化手法を提案しています。
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)
マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）の再最適化ラベルスイッチドパス（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).
Copyright（c）The IETF Trust（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.
このドキュメントでは、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）でシグナルとされた、緩やかにルーティングされたMPLSおよびGMPLS（一般化されたマルチプロトコルラベルスイッチング）トラフィックエンジニアリング（TE）ラベルスイッチパス（LSP）の再最適化のメカニズムを定義します。このドキュメントでは、TE LSPヘッドエンドラベルスイッチングルーター（LSR）が、次のホップがルーズまたは抽象ホップとして定義され、シグナルの中間点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).
このドキュメントは、RSVP-TEでシグナルとされた、緩やかにルーティングされたMPLSおよびGMPLS（一般化されたマルチプロトコルラベルスイッチング）トラフィックエンジニアリングLSPの再発現のメカニズムを定義します（[RFC3209]および[RFC3473]を参照）。ゆるくルーティングされたLSPは、Ingress LSRによって信号を送られた時点で、LSPの経路に沿って各LSRを識別する完全で明示的なルートを含まないものとして定義されます。このようなLSPは、明示的なルートオブジェクト（ERO）なし、少なくとも1つのルースホップを含む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:
トラフィックエンジニアリングワーキンググループ（TE WG）は、エリア間およびMPLSトラフィックエンジニアリングの一連の要件を指定しています（[RFC4105]および[RFC4216]を参照）。両方の要件文書は、下流のドメイン（IGP領域または自律システム）により最適なパスが存在する場合、ヘッドエンドLSRが再最適なパスが存在する場合に、ヘッドエンドLSRが再最適化プロセスを制御するオプションを提供するいくつかのメカニズムの必要性を指定します。このドキュメントは、この要件を満たすためのソリューションを定義し、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) 最初のメカニズムにより、ヘッドエンド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がヘッドエンドLSRに明示的に信号を送ることができます（現在のパスと比較して）ゆるい/抽象ホップに到達するためのより良いパスが存在するか、メンテナンスのためにTE LSPを再最適化する必要があります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.
Interior Gateway Protocol Area (IGP Area): OSPF Area or IS-IS level.
インテリアゲートウェイプロトコル領域（IGPエリア）：OSPFエリアまたはIS-ISレベル。
Intra-area TE LSP: A TE LSP whose path does not transit across areas.
Intra-Areae LSP：パスがエリア全体で通過しないTE LSP。
Inter-area TE LSP: A TE LSP whose path transits across at least two different IGP areas.
Inter-Areae LSP：少なくとも2つの異なる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).
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は、Ingress LSRによって信号を送られた時点で、LSPの経路に沿って各LSRを識別する完全で明示的なルートを含まないものとして定義されます。このようなLSPは、EROなし、少なくとも1つのルースホップを含むERO、または単純な抽象ノードではない抽象ノード（つまり、複数のLSRを識別する抽象ノード）を含むEROを備えています。。[RFC3209]で指定されているように、ルーズホップは、IPv4またはIPv6プレフィックスサブオブジェクトセットのLフラグを使用して、RSVPパスメッセージの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).
次のホップがルーズホップまたは非固有の抽象ノードとして指定されているパスに沿った各LSRは、RSVPパスメッセージを下流に転送する前に、パス計算（ERO拡張とも呼ばれます）をトリガーします。計算されたパスは、部分的な（次のルーズホップまで）または完全な（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間地域のコンテキストで提供されているが、提案されたメカニズムは、単一のルーティングドメイン内および複数の自律システム全体でゆるくルーティングされたパスに等しく適用されることに注意してください。以下の例は、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.
- R1（ヘッドエンドLSR）からR11（テールエンドLSR）へのインターエアリーLSP T1のパスは、R1で次のゆるいルーティングパスとして定義されています：R1-R3（緩んでいる）-R8（ルーズ）-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に直接接続されていない）であると判断し、ERO拡張操作を実行して次のルーズホップR3に到達します。新しいEROは：R2（S）-R3（S）-R8（L）-R11（L）になります。Sは厳密なホップ（L = 0）、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パスメッセージは、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に直接接続されていない）であると判断し、ERO拡張操作を実行して次のルーズホップR8に到達します。新しいEROは、R6（S）-R7（S）-R8（S）-R11（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：同じ手順がR8によって繰り返され、T1の宛先（R11）に到達します。
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の寿命の間、LSRとその次のルーズホップの間により最適なパスが現れる可能性があります（図のために、上記の例では、R6とR8の間のリンクが追加または復元され、R3間の好ましいパスを提供すると仮定します。既存のR3-R6-R7-R8パスよりもR8（R3-R6-R8）。ヘッドエンドLSRが関連するトポロジの変化が発生したのと同じIGP領域に属していない場合、IGPによってヘッドエンドLSRから好ましい（たとえば短い）パスが見えない可能性があるため、ヘッドエンドはできません必要に応じて、この短いパスを使用します（[RFC3209]で説明されているように、Make-Be-Breake-Be-Breake-Brek-Brekemy Technikeを使用して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（RSVP PatherRメッセージに掲載された新しいエラー値サブコードを使用）をヘッドエンドLSRに、好ましいパスが存在することを示しています（コスト定義は何らかのメトリックによって決定される低コスト。
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の特性に応じて）「Make-Be-Break」手順などの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.
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 Rerouteをトリガーするのではなく、代わりに、望ましいパスが存在するかどうかを評価するリクエストを信号するだけであることに注意してください。
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.
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パスメッセージをすぐに送信します。このビットは、下流の後続のRSVPパスメッセージでクリアされます。失われたパスメッセージのケースを処理するために、ソリューションは[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: A path re-evaluation is triggered, and the newly computed path is compared to the existing path:
「パス再評価リクエスト」ビットセットでパスメッセージを受信すると、EROに含まれる次の抽象ノードがルーズホップ/抽象ノードとして定義されているすべてのLSRが次の一連のアクションを実行します。パスの再評価トリガーされ、新しく計算されたパスは既存のパスと比較されます。
- 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は、すぐにRSVP PatherrをヘッドエンドLSRに送信する必要があります（エラーコード25（Notify）、エラーサブコード= 6（より良いパスが存在します））。この時点で、LSRは、再評価されたTE LSPの下流で送信されるその後のRSVPパスメッセージでこのビットを伝播しないことを決定する場合があります。このモードは、以下で説明する理由から推奨モードです。
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に「好ましいパスが存在する」メッセージに通知することで、ヘッドエンドLSRに好ましいパスの存在を通知します（たとえば、下流の領域/ASまたは単一のドメイン内の別の場所で通知します）。したがって、下流ノードでの追加のパスの再評価をトリガーすることは不要です。セッションアトリブオブジェクトセットの「パス再評価リクエスト」ビットを使用して後続のRSVPパスメッセージを転送する唯一の動機は、下流ノードのパスの再評価をトリガーすることです。シグナリングセットアップの遅延を減らすことを目的で、ヘッドエンド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パスメッセージが失われた場合、次のリクエストが送信されます。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はRSVP PATHERRをヘッドエンドLSR（エラーコード25（NOTIFY）、エラーサブコード= 6（「好ましいパスが存在する」）に送信します。
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が、TE LSPがヘッドエンドLSRによって再ルーティングされる目的で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.
-
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.
2つの機能（ヘッドエンド駆動型と中点駆動型）は互いに排他的ではないことに注意してください。タイマーとイベント駆動型の再オプチミー化トリガーは、ヘッドエンドまたは潜在的に異なる異なる任意の中間点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がブレイク前に実行するとパスを再計算する必要がないように、限られた時間の時間をポイントします。このモードはオプションです。キャッシュタイマーのデフォルト値は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].
このドキュメントに記載されている手順をサポートしないことを選択するIngressの実装は、下流ドメインでより最適なものが利用可能かどうかを発見しようとすることなく、LSPの投機的なメイク前に定期的に発行することにより、再最適化を達成する可能性があります。このような手順は、[RFC3209]および[RFC3473]ですでに文書化されているメカニズムと矛盾するものではありません。
An LSR not supporting the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object SHALL forward it unmodified.
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.
IANA assigned three new error sub-code values for the RSVP PathErr Notify message (Error code=25):
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.
このドキュメントでは、中間点LSRのメカニズムが、ヘッドエンドLSRに好ましいパスの存在を通知するか、メンテナンスのためにTE LSPを再ルーティングする必要性を通知します。したがって、複数の管理ドメインにまたがるTE LSPの場合、境界LSRがRSVP PATHERRメッセージ（コード25、エラーサブコード= 6、7、または8）を変更することが望ましい場合があります。ドメイン。さらに、ヘッドエンド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.
著者は、キャロル・イトゥルラデ、ミヤ・コノ、フランソワ・ル・ファウチュール、フィリップ・マシューズ、ジム・ギブソン、ジャン・ルイス・ル・ルー、kenji kumaki、anca zafir、およびdimitri papadimitriouに有用なコメントに感謝したいと思います。彼の非常に貴重なインプットに感謝します。
[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月。
[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月。
[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トンネルの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.
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105] Le Roux、J.-L.、Vasseur、J.-P.、およびJ. Boyle、「エリア間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] Zhang、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（編集者）Cisco Systems、Inc 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-8019 Japan
Yuichi Ikejiri ntt Communications Corporation 1-1-6、Uchisaiwai-Cho、Chiyoda-Ku Tokyo、100-8019 Japan
EMail: y.ikejiri@ntt.com
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
Raymond Zhang Bt Infonet 2160 E. Grand Ave. El Segundo、CA 90025 USA
EMail: raymond_zhang@bt.infonet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。