[要約] RFC 4090は、LSPトンネルのためのRSVP-TEの高速再ルート拡張に関するものです。このRFCの目的は、ネットワークの障害時にトンネルの再ルーティングを迅速かつ効果的に行うための手法を提供することです。
Network Working Group P. Pan, Ed.
Request for Comments: 4090 Hammerhead Systems
Category: Standards Track G. Swallow, Ed.
Cisco Systems
A. Atlas, Ed.
Avici Systems
May 2005
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
LSPトンネルのRSVP-TEへの拡張機能を高速に再表示します
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.
このドキュメントでは、RSVP-TE拡張機能を定義して、LSPトンネルのローカル修理のためのバックアップラベルスイッチパス（LSP）トンネルを確立します。これらのメカニズムにより、障害が発生した場合に、10分の1ミリ秒でバックアップLSPトンネルへのトラフィックを再方向にすることができます。
Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network.
ここでは、2つの方法が定義されています。1対1のバックアップメソッドは、ローカル修理の各潜在的なポイントで保護された各LSPに対して迂回LSPを作成します。施設のバックアップ方法は、潜在的な障害点を保護するためにバイパストンネルを作成します。MPLSラベルスタッキングを利用することにより、このバイパストンネルは、同様のバックアップ制約を持つLSPのセットを保護できます。両方の方法を使用して、ネットワーク障害中のリンクとノードを保護できます。記載されている動作とRSVPへの拡張により、ノードはメソッドまたはその両方を実装し、混合ネットワークで相互運用することができます。
Table of Contents
目次
1. Introduction ...................................................3
1.1. Background ...............................................4
2. Terminology ....................................................4
3. Local Repair Techniques ........................................6
3.1. One-to-One Backup ........................................6
3.2. Facility Backup ..........................................7
4. RSVP Extensions ................................................8
4.1. FAST_REROUTE Object ......................................8
4.2. DETOUR Object ...........................................11
4.2.1. DETOUR Object for IPv4 Address ...................11
4.2.2. DETOUR Object for IPv6 Address ...................12
4.3. SESSION_ATTRIBUTE Flags .................................13
4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14
5. Head-End Behavior .............................................15
6. Point of Local Repair (PLR) Behavior ..........................16
6.1. Signaling a Backup Path .................................17
6.1.1. Backup Path Identification: Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ........19
6.2. Procedures for Backup Path Computation ..................20
6.3. Signaling Backups for One-to-One Protection .............21
6.3.1. Make-before-Break with Detour LSPs ...............22
6.3.2. Message Handling .................................23
6.3.3. Local Reroute of Traffic onto Detour LSP .........23
6.4. Signaling for Facility Protection .......................24
6.4.1. Discovering Downstream Labels ....................24
6.4.2. Procedures for the PLR before Local Repair .......24
6.4.3. Procedures for the PLR during Local Repair .......25
6.4.4. Processing Backup Tunnel's ERO ...................26
6.5. PLR Procedures during Local Repair ......................26
6.5.1. Notification of Local Repair .....................26
6.5.2. Revertive Behavior ...............................27
7. Merge Node Behavior ...........................................28
7.1. Handling Backup Path Messages before Failure ............28
7.1.1. Merging Backup Paths using the Sender
Template-Specific Method .........................29
7.1.2. Merging Detours using the Path-Specific Method ...29
7.1.3. Message Handling for Merged Detours ..............31
7.2. Handling Failures .......................................31
8. Behavior of All LSRs ..........................................32
8.1. Merging Detours in the Path-Specific Method .............32
9. Security Considerations .......................................33
10. IANA Considerations ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................36
This document extends RSVP [RSVP] to establish backup label-switched path (LSP) tunnels for the local repair of LSP tunnels. This extension will meet the needs of real-time applications such as voice over IP, for which user traffic should be redirected onto backup LSP tunnels in 10s of milliseconds. This timing requirement can be satisfied by computing and signaling backup LSP tunnels in advance of failure and by re-directing traffic as close to the failure point as possible. In this way, the time for redirection includes no path computation and no signaling delays, including delays to propagate failure notification between label-switched routers (LSRs). Speed of repair is the primary advantage of the methods and extensions described here. The term local repair is used when referring to techniques that re-direct traffic to a backup LSP tunnel in response to a local failure.
このドキュメントはRSVP [RSVP]を拡張して、LSPトンネルの局所修理のためのバックアップラベルスイッチパス（LSP）トンネルを確立します。この拡張機能は、10ミリ秒でユーザートラフィックをバックアップLSPトンネルにリダイレクトする必要があるIPオーバーIPなどのリアルタイムアプリケーションのニーズを満たします。このタイミングの要件は、障害の前にLSPトンネルを計算および信号を送信し、トラフィックを可能な限り故障ポイントに近づけることにより、満たすことができます。このように、リダイレクトの時間には、パス計算がなく、シグナルの遅延が含まれていません。これには、ラベルスイッチルーター（LSR）間の故障通知を伝播する遅延が含まれます。修理速度は、ここで説明する方法と拡張機能の主な利点です。局所的な修理という用語は、ローカルの障害に応じてトラフィックをバックアップLSPトンネルに再ダイレクトする手法を参照するときに使用されます。
A protected LSP is an explicitly-routed LSP that is provided with protection. The repair methods described here are applicable only to explicitly-routed LSPs. Application of these methods to LSPs that dynamically change their routes, such as LSPs used in unicast IGP routing, is beyond the scope of this document.
保護されたLSPは、保護を備えた明示的にルーティングされたLSPです。ここで説明する修復方法は、明示的にルーティングされたLSPにのみ適用されます。ユニキャストIGPルーティングで使用されるLSPなど、ルートを動的に変更するLSPにこれらの方法を適用することは、このドキュメントの範囲を超えています。
Section 2 covers new terminology used in this document. Section 3 describes two basic methods for creating backup LSPs. Section 4 describes the RSVP protocol extensions to support local protection. Section 5 presents the behavior of an LSR that seeks to request local protection for an LSP. The behavior of a potential point of local repair (PLR) is given in Section 6, which describes how to determine the appropriate strategy for protecting an LSP and how to implement each of the strategies. Section 7 describes the behavior of a merge node, the LSR where a protected LSP and its backup LSP rejoin. Finally, Section 8 discusses the required behavior of other nodes in the network.
セクション2では、このドキュメントで使用されている新しい用語について説明します。セクション3では、バックアップLSPを作成するための2つの基本的な方法について説明します。セクション4では、ローカル保護をサポートするRSVPプロトコル拡張について説明します。セクション5では、LSPのローカル保護を要求しようとするLSRの動作を示しています。局所修理の潜在的な点（PLR）の動作はセクション6に示されています。これは、LSPを保護するための適切な戦略を決定する方法と、各戦略を実装する方法について説明します。セクション7では、保護されたLSPとそのバックアップLSPが再加行するLSRであるマージノードの動作について説明します。最後に、セクション8では、ネットワーク内の他のノードの必要な動作について説明します。
The methods discussed in this document depend upon three assumptions:
このドキュメントで説明した方法は、3つの仮定に依存します。
o An LSR that is on the path of a protected LSP should always assume that it is a merge point. This is necessary because the facility backup method does not signal backups through a bypass tunnel before failure.
o 保護されたLSPの経路にあるLSRは、常にマージポイントであると仮定する必要があります。施設のバックアップ方法は、故障前にバイパストンネルを介してバックアップを通知しないため、これが必要です。
o If the one-to-one backup method is used and a DETOUR object is included, the LSRs in the traffic-engineered network should support the DETOUR object. This is necessary so that the Path message containing the DETOUR object is not rejected.
o 1対1のバックアップメソッドが使用され、迂回オブジェクトが含まれている場合、トラフィックエンジニアリングネットワークのLSRは迂回オブジェクトをサポートする必要があります。これは、迂回オブジェクトを含むパスメッセージが拒否されないようにするために必要です。
o Understanding the DETOUR object is required to support the path-specific method, which requires that LSRs in the traffic-engineered network be capable of merging detours.
o 迂回オブジェクトを理解するには、パス固有の方法をサポートする必要があります。これには、トラフィックエンジニアリングネットワーク内のLSRが迂回路を統合できる必要があります。
Several years before work began on this document, operational networks had deployed two independent methods of doing fast reroute; these methods are called here one-to-one backup and facility backup. Vendors trying to support both methods experienced compatibility problems in attempting to produce a single implementation capable of interoperating with both methods. There are technical tradeoffs between the methods. These tradeoffs are so topologically dependent that the community has not converged on a single approach.
このドキュメントの作業が始まる数年前に、運用ネットワークは、速いルートを行う2つの独立した方法を展開していました。これらの方法は、ここで1対1のバックアップと施設のバックアップと呼ばれます。両方の方法をサポートしようとするベンダーは、両方の方法で相互運用できる単一の実装を作成しようとする際に互換性の問題を経験しました。方法の間には技術的なトレードオフがあります。これらのトレードオフは非常にトポロジカルに依存しているため、コミュニティは単一のアプローチに収束していません。
This document rationalizes the RSVP signaling for both methods so that any implementation can recognize all fast reroute requests and clearly respond. The response may be positive if the method can be performed, or it may be a clear error to inform the requester to seek alternate backup means. This document also allows a single implementation to support both methods, thereby providing a range of capabilities. The described behavior and extensions to RSVP allow LERs and LSRs to implement either method or both.
このドキュメントは、両方の方法のRSVPシグナリングを合理化し、実装がすべての高速リルート要求を認識し、明確に応答できるようにします。メソッドを実行できる場合、応答は肯定的である場合があります。または、リクエスターに代替バックアップ手段を求めるように通知することは明確なエラーである場合があります。また、このドキュメントでは、両方の方法をサポートする単一の実装を可能にするため、さまざまな機能を提供します。記述された動作とRSVPへの拡張により、LERとLSRがメソッドまたはその両方を実装できます。
While the two methods could in principle be used in a single network, it is expected that operators will continue to deploy either one or the other. The goal of this document is to standardize the RSVP signaling so that a network composed of LSRs that implement both methods or a network composed of some LSRs that support one method and others that support both can properly signal among those LSRs to achieve fast restoration.
2つの方法は原則として単一のネットワークで使用できますが、オペレーターはどちらか一方を展開し続けることが期待されています。このドキュメントの目標は、RSVPシグナル伝達を標準化することで、1つの方法をサポートするLSRとその両方をサポートする他のLSRで構成されるLSRの両方で構成されるネットワークが、それらのLSR間で適切にシグナルを送信して高速回復を実現できるようにすることです。
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 RFC2119 [RFC-WORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC2119 [RFC-Words]で説明されているように解釈されます。
The reader is assumed to be familiar with the terminology in [RSVP] and [RSVP-TE].
読者は、[RSVP]および[RSVP-TE]の用語に精通していると想定されています。
LSR: Label-Switch Router.
LSR：ラベルスイッチルーター。
LSP: An MPLS Label-Switched Path. In this document, an LSP will always be explicitly routed.
LSP：MPLSラベルスイッチパス。このドキュメントでは、LSPは常に明示的にルーティングされます。
Local Repair: Techniques used to repair LSP tunnels quickly when a node or link along the LSP's path fails.
ローカルの修理：LSPのパスに沿ったノードまたはリンクが失敗したときにLSPトンネルを迅速に修復するために使用される技術。
PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP.
PLR：ローカル修理のポイント。バックアップトンネルまたは迂回路LSPのヘッドエンドLSR。
One-to-One Backup: A local repair method in which a backup LSP is separately created for each protected LSP at a PLR.
1対1のバックアップ：PLRで保護されたLSPごとにバックアップLSPが個別に作成されるローカル修理方法。
Facility Backup: A local repair method in which a bypass tunnel is used to protect one or more protected LSPs that traverse the PLR, the resource being protected, and the Merge Point in that order.
施設のバックアップ：PLRを横断する1つまたは複数の保護されたLSP、保護されているリソース、およびその順序のマージポイントを保護するためにバイパストンネルを使用するローカル修理方法。
Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop.
保護されたLSP：LSPは、そのホップで1つまたは複数の関連するバックアップトンネルがある場合、特定のホップで保護されていると言われています。
Detour LSP: The LSP that is used to re-route traffic around a failure in one-to-one backup.
Detour LSP：1対1のバックアップでの障害の周りのトラフィックを再ルーティングするために使用されるLSP。
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.
バイパストンネル：一般的な施設を通過するLSPのセットを保護するために使用されるLSP。
Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup.
バックアップトンネル：多くのLSPの1つをバックアップするために使用されるLSP。
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single link of the protected LSP.
NHOPバイパストンネル：Next-Hopバイパストンネル。保護されたLSPの単一のリンクをバイパスするバックアップトンネル。
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single node of the protected LSP.
nnhopバイパストンネル：次のネクストホップバイパストンネル。保護されたLSPの単一ノードをバイパスするバックアップトンネル。
Backup Path: The LSP that is responsible for backing up one protected LSP. A backup path refers to either a detour LSP or a backup tunnel.
バックアップパス：保護された1つのLSPのバックアップを担当するLSP。バックアップパスは、迂回路LSPまたはバックアップトンネルのいずれかを指します。
MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. The same LSR may be both an MP and a PLR simultaneously.
MP：マージポイント。1つ以上のバックアップトンネルが潜在的な障害の下流の保護されたLSPの経路に再結合するLSR。同じLSRは、MPとPLRの両方である場合があります。
DMP: Detour Merge Point. In the case of one-to-one backup, this is an LSR where multiple detours converge. Only one detour is signaled beyond that LSR.
DMP：マージポイントを迂回します。1対1のバックアップの場合、これは複数の迂回が収束するLSRです。そのLSRを超えて1つの迂回路のみが合図されています。
Reroutable LSP: Any LSP for which the head-end LSR requests local protection. See Section 5 for more detail.
再登録可能なLSP：ヘッドエンドLSRがローカル保護を要求するLSP。詳細については、セクション5を参照してください。
CSPF: Constraint-based Shortest Path First.
CSPF：最初に制約ベースの最短パス。
SRLG Disjoint: A path is considered to be SRLG disjoint from a given link or node if the path does not use any links or nodes which belong to the same SRLG as that given link or node.
srlg disjoint：パスが指定されたリンクまたはノードと同じsrlgに属するリンクまたはノードを使用しない場合、特定のリンクまたはノードからのsrlgの分離と見なされます。
Two different methods for local protection are described. In the one-to-one backup method, a PLR computes a separate backup LSP, called a detour LSP, for each LSP that the PLR protects. In the facility backup method, the PLR creates a single bypass tunnel that can be used to protect multiple LSPs.
局所保護のための2つの異なる方法について説明します。1対1のバックアップメソッドでは、PLRがPLRが保護する各LSPに対して、Detour LSPと呼ばれる個別のバックアップLSPを計算します。施設のバックアップ方法では、PLRは複数のLSPを保護するために使用できる単一のバイパストンネルを作成します。
In the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure. A separate backup LSP is established for each LSP that is backed up.
1対1のバックアップ方法では、リンクまたはノード障害の下流のどこかで元のLSPと交差するラベルスイッチされたパスが確立されます。バックアップされた各LSPに対して別のバックアップLSPが確立されます。
[R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ /
[R6]----[R7]----[R8]------[R9]
Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R3]
R2's Backup: [R2->R7->R8->R4]
R3's Backup: [R3->R8->R9->R5]
R4's Backup: [R4->R9->R5]
Example 1. One-to-One Backup Technique
例1. 1対1のバックアップ手法
In the simple topology shown in Example 1, the protected LSP runs from R1 to R5. R2 can provide user traffic protection by creating a partial backup LSP that merges with the protected LSP at R4. We refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a detour.
例1に示す単純なトポロジでは、保護されたLSPはR1からR5に実行されます。R2は、R4で保護されたLSPと融合する部分的なバックアップLSPを作成することにより、ユーザーのトラフィック保護を提供できます。部分的な1対1のバックアップLSP [R2-> R7-> R8-> R4]を迂回と呼びます。
To protect an LSP that traverses N nodes fully, there could be as many as (N - 1) detours. Example 1 shows the paths for the detours necessary to protect fully the LSP in the example. To minimize the number of LSPs in the network, it is desirable to merge a detour back to its protected LSP, when feasible. When a detour LSP intersects its protected LSP at an LSR with the same outgoing interface, it will be merged.
Nノードを完全に通過するLSPを保護するために、（n -1）迂回路がある可能性があります。例1は、例のLSPを完全に保護するために必要な迂回路のパスを示しています。ネットワーク内のLSPの数を最小限に抑えるには、実行可能な場合は、迂回路を保護されたLSPに融合させることが望ましいです。迂回路LSPが同じ発信インターフェイスでLSRで保護されたLSPを交差させると、マージされます。
When a failure occurs along the protected LSP, the PLR redirects traffic onto the local detour. For instance, if the link [R2->R3] fails in Example 1, R2 will switch traffic received from R1 onto the protected LSP along link [R2->R7], using the label received when R2 created the detour. When R4 receives traffic with the label provided for R2's detour, R4 will switch that traffic onto link [R4-R5], using the label received from R5 for the protected LSP. At no point does the depth of the label stack increase as a result of the detour. While R2 is using its detour, traffic will take the path [R1->R2->R7->R8->R4->R5].
保護されたLSPに沿って障害が発生すると、PLRはトラフィックを地元の迂回路にリダイレクトします。たとえば、リンク[R2-> R3]が例1で失敗した場合、R2はR1からリンク[R2-> R7]に沿って保護されたLSPに受信されたトラフィックを切り替えます。R4がR2の迂回路用に提供されるラベルでトラフィックを受け取ると、R4は保護されたLSPのR5から受信したラベルを使用して、そのトラフィックをリンク[R4-R5]に切り替えます。迂回路の結果として、ラベルスタックの深さが増加することはありません。R2が迂回路を使用している間、トラフィックはパス[R1-> R2-> R7-> R8-> R4-> R5]を使用します。
The facility backup method takes advantage of the MPLS label stack. Instead of creating a separate LSP for every backed-up LSP, a single LSP is created that serves to back up a set of LSPs. We call such an LSP tunnel a bypass tunnel.
施設のバックアップ方法は、MPLSラベルスタックを利用します。バックアップされたLSPごとに個別のLSPを作成する代わりに、LSPのセットをバックアップするのに役立つ単一のLSPが作成されます。このようなLSPトンネルをバイパストンネルと呼びます。
The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. Naturally, this constrains the set of LSPs being backed up via that bypass tunnel to those that pass through some common downstream node. All LSPs that pass through the point of local repair and through this common node that do not also use the facilities involved in the bypass tunnel are candidates for this set of LSPs.
バイパストンネルは、PLRの下流のどこかで元のLSPの経路を交差させる必要があります。当然のことながら、これにより、そのバイパストンネルを介してバックアップされるLSPのセットが、一般的な下流ノードを通過するトンネルに制約します。ローカル修理のポイントを通過し、バイパストンネルに関与する施設を使用しないこの一般的なノードを通過するすべてのLSPは、このLSPのセットの候補です。
[R8]
\
[R1]---[R2]----[R3]-----[R4]---[R5]
\ / \
[R6]===[R7] [R9]
Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4]
Example 2. Facility Backup Technique
例2.施設のバックアップ手法
In Example 2, R2 has built a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. The doubled lines represent this tunnel. This technique provides a scalability improvement, in that the same bypass tunnel can also be used to protect LSPs from any of R1, R2, or R8 to any of R4, R5, or R9. Example 2 describes three different protected LSPs that are using the same bypass tunnel for protection.
例2では、R2はリンク[R2-> R3]およびノード[R3]の故障を防ぐバイパストンネルを構築しました。二重線はこのトンネルを表しています。この手法は、同じバイパストンネルを使用して、R1、R2、またはR8のいずれかからR4、R5、またはR9のいずれかにLSPを保護するためにも使用できるという点で、スケーラビリティの改善を提供します。例2では、同じバイパストンネルを使用して保護のために3つの異なる保護されたLSPを説明しています。
As with the one-to-one method, there could be as many as (N-1) bypass tunnels to fully protect an LSP that traverses N nodes. However, each of those bypass tunnels could protect a set of LSPs.
1対1の方法と同様に、nノードを横断するLSPを完全に保護するために、an（n-1）バイパストンネルがある可能性があります。ただし、これらのバイパストンネルのそれぞれは、LSPのセットを保護できます。
When a failure occurs along a protected LSP, the PLR redirects traffic into the appropriate bypass tunnel. For instance, if link [R2->R3] fails in Example 2, R2 will switch traffic received from R1 on the protected LSP onto link [R2->R6]. The label will be switched for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto the label-stack of the redirected packets. If penultimate-hop-popping is used, the merge point in Example 2, R4, will receive the redirected packet with a label indicating the protected LSP that the packet is to follow. If penultimate-hop-popping is not used, R4 will pop the bypass tunnel's label and examine the label underneath to determine the protected LSP that the packet is to follow. When R2 is using the bypass tunnel for protected LSP 1, the traffic takes the path [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection between R2 and R4.
保護されたLSPに沿って障害が発生すると、PLRはトラフィックを適切なバイパストンネルにリダイレクトします。たとえば、リンク[R2-> R3]が例2で失敗した場合、R2は保護されたLSPのR1から受信したトラフィックをリンク[R2-> R6]に切り替えます。ラベルは、保護されたLSPを示すためにR4によって理解されるものに対して切り替えられ、バイパストンネルのラベルはリダイレクトされたパケットのラベルスタックに押し込まれます。最後から2番目のホップポッピングを使用すると、例2のマージポイント、R4は、パケットが従うべき保護されたLSPを示すラベルを備えたリダイレクトパケットを受け取ります。最後から2番目のホップポッピングが使用されない場合、R4はバイパストンネルのラベルをポップし、その下のラベルを調べて、パケットが従うべき保護されたLSPを決定します。R2が保護されたLSP 1にバイパストンネルを使用している場合、トラフィックはパス[R1-> R2-> R6-> R7-> R4-> R5];バイパストンネルは、R2とR4の間の接続です。
This specification defines two additional objects, FAST_REROUTE and DETOUR, to extend RSVP-TE for fast-reroute signaling. These new objects are backward compatible with LSRs that do not recognize them (see section 3.10 in [RSVP]). Both objects can only be carried in RSVP Path messages.
この仕様では、Fast_rerouteとDetourの2つの追加オブジェクトを定義して、RSVP-TEを高速レアウトシグナリングのために拡張します。これらの新しいオブジェクトは、それらを認識しないLSRとの後方互換性があります（[RSVP]のセクション3.10を参照）。両方のオブジェクトは、RSVPパスメッセージでのみ運ばれます。
The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to support bandwidth and node protection features.
session_attribute and Record_routeオブジェクトは、帯域幅とノードの保護機能をサポートするために拡張されています。
The FAST_REROUTE object is used to control the backup used for the protected LSP. This specifies the setup and hold priorities, session attribute filters, and bandwidth to be used for protection. It also allows a specific local protection method to be requested. This object MUST only be inserted into the PATH message by the head-end LER and MUST NOT be changed by downstream LSRs. The FAST_REROUTE object has the following format:
FAST_REROUTEオブジェクトは、保護されたLSPに使用されるバックアップを制御するために使用されます。これは、セットアップと保持優先順位、セッション属性フィルター、および保護に使用する帯域幅を指定します。また、特定のローカル保護方法を要求することもできます。このオブジェクトは、ヘッドエンドLERによってパスメッセージにのみ挿入する必要があり、下流のLSRによって変更されないでください。fast_rerouteオブジェクトには、次の形式があります。
Class-Num = 205 C-Type = 1
class-num = 205 c-type = 1
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
| Include-all |
+-------------+-------------+-------------+-------------+
Setup Priority
セットアップの優先順位
The priority of the backup path with respect to taking resources, in the range 0 to 7. The value 0 is the highest priority. Setup Priority is used in deciding whether this session can preempt another session. See [RSVP-TE] for the usage on priority.
0〜7の範囲で、リソースの取得に関するバックアップパスの優先度は、値0が最優先事項です。セットアップの優先順位は、このセッションが別のセッションを先取りできるかどうかを決定する際に使用されます。優先度に関する使用については、[RSVP-TE]を参照してください。
Holding Priority
優先順位を保持します
The priority of the backup path with respect to holding resources, in the range 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. See [RSVP-TE] for the usage on priority.
0〜7の範囲の保持リソースに関するバックアップパスの優先度は、値0が最優先事項です。保持優先度は、このセッションを別のセッションで先取りできるかどうかを決定する際に使用されます。優先度に関する使用については、[RSVP-TE]を参照してください。
Hop-limit
ホップリミット
The maximum number of extra hops the backup path is allowed to take, from current node (a PLR) to an MP, with PLR and MP excluded from the count. For example, hop-limit of 0 means that only direct links between PLR and MP can be considered.
最大数の追加ホップ数バックアップパスは、現在のノード（PLR）からMPまで、PLRとMPはカウントから除外されています。たとえば、0のホップリミットは、PLRとMPの間の直接リンクのみを考慮することができることを意味します。
Flags
フラグ
0x01 One-to-One Backup Desired
0x01 1対1のバックアップが必要です
Requests protection via the one-to-one backup method.
1対1のバックアップメソッドを介して保護を要求します。
0x02 Facility Backup Desired
0x02施設のバックアップが必要です
Requests protection via the facility backup method.
施設のバックアップ方法を介して保護を要求します。
Bandwidth
帯域幅
Bandwidth estimate; 32-bit IEEE floating point integer, in bytes per second.
帯域幅の見積もり。32ビットIEEEフローティングポイント整数、1秒あたりのバイト。
Exclude-any
除外 - any
A 32-bit vector representing a set of attribute filters associated with a backup path, any of which renders a link unacceptable.
バックアップパスに関連付けられた属性フィルターのセットを表す32ビットベクトルは、いずれかがリンクを受け入れられないレンダリングします。
Include-any
include-any
A 32-bit vector representing a set of attribute filters associated with a backup path, any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
バックアップパスに関連付けられた属性フィルターのセットを表す32ビットベクトル。いずれかがリンクを許容可能にします（このテストに関して）。nullセット（すべてのビットセットがゼロに設定）が自動的に通過します。
Include-all
include-all
A 32-bit vector representing a set of attribute filters associated with a backup path, all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
バックアップパスに関連付けられた属性フィルターのセットを表す32ビットベクトル。これらはすべて、このテストに関して）を許容できるようにするために存在する必要があります。nullセット（すべてのビットセットがゼロに設定）が自動的に通過します。
The two high-order bits of the Class-Num (11) cause nodes that do not understand the object to ignore it and pass it forward unchanged.
クラスナム（11）の2つの高次ビットは、オブジェクトを理解していないノードを無視して変化させないノードを引き起こします。
For informational purposes, a different C-Type value and format for the FAST_REROUTE object are specified below. This is used by legacy implementations. The meaning of the fields is the same as that described for C-Type 1.
情報目的のために、FAST_REROUTEオブジェクトの異なるCタイプの値と形式を以下に指定します。これは、レガシーの実装で使用されます。フィールドの意味は、Cタイプ1について説明したものと同じです。
Class-Num = 205 C-Type = 7
class-num = 205 c-type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
未知のCタイプは、[RSVP]セクション3.10で指定されているように扱う必要があります。
The DETOUR object is used in the one-to-one backup method to identify detour LSPs.
迂回路オブジェクトは、1対1のバックアップ方法で使用され、迂回路LSPを識別します。
Class-Num = 63 C-Type = 7
class-num = 63 c-type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| PLR_ID n |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID n |
+-------------+-------------+-------------+-------------+
PLR_ID (1 - n)
plr_id（1 -n）
IPv4 address identifying the PLR that is the beginning point of the detour. Any local address on the PLR can be used.
IPv4アドレスは、迂回路の開始点であるPLRを識別します。PLRのローカルアドレスを使用できます。
Avoid_Node_ID (1 - n)
evess_node_id（1 -n）
IPv4 address identifying the immediate downstream node that the PLR is trying to avoid. Any local address of the downstream node can be used. This field is mandatory and is used by the MP for the merging rules discussed below.
IPv4アドレスは、PLRが回避しようとしている即時の下流ノードを識別します。下流ノードのローカルアドレスを使用できます。このフィールドは必須であり、以下で説明するマージルールのためにMPによって使用されます。
Class-Num = 63 C-Type = 8
class-num = 63 c-type = 8
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
PLR_ID (1 - n)
plr_id（1 -n）
An IPv6 128-bit unicast host address identifying the PLR that is the beginning point of the detour. Any local address on the PLR can be used.
迂回の開始点であるPLRを識別するIPv6 128ビットユニキャストホストアドレス。PLRのローカルアドレスを使用できます。
Avoid_Node_ID (1 - n)
evess_node_id（1 -n）
An IPv6 128-bit unicast host address identifying the immediate downstream node that the PLR is trying to avoid. Any local address on the downstream node can be used. This field is mandatory and is used by the MP for the merging rules discussed below.
IPv6 128ビットユニキャストホストアドレスは、PLRが回避しようとしている即時の下流ノードを識別します。ダウンストリームノードのローカルアドレスを使用できます。このフィールドは必須であり、以下で説明するマージルールのためにMPによって使用されます。
There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in a DETOUR object. If detour merging is desired, after each merging operation, the Detour Merge Point should combine all the merged detours in subsequent Path messages.
迂回オブジェクトには、複数のペア（plr_id、resse_node_id）エントリがあります。迂回操作が必要な場合、各マージ操作の後、迂回路のマージポイントは、その後のパスメッセージでマージされたすべての迂回を組み合わせる必要があります。
The high-order bit of the Class-Num is zero; LSRs that do not support the DETOUR objects MUST reject any Path message containing a DETOUR object and send a PathErr to notify the PLR. This PathErr SHOULD be generated as specified in [RSVP] for unknown objects with a Class-Num of the form "0bbbbbbb".
クラスナムの高次ビットはゼロです。迂回オブジェクトをサポートしていないLSRは、迂回オブジェクトを含むパスメッセージを拒否し、PATHERRを送信してPLRに通知する必要があります。このPatherrは、フォーム「0bbbbbbbb」のクラス番号を持つ未知のオブジェクトの[rsvp]で指定されているように生成する必要があります。
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
未知のCタイプは、[RSVP]セクション3.10で指定されているように扱う必要があります。
To request bandwidth and node protection explicitly, two new flags are defined in the SESSION_ATTRIBUTE object.
帯域幅とノード保護を明示的に要求するために、2つの新しいフラグがSession_Attributeオブジェクトで定義されています。
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has the following flags defined [RSVP-TE]:
Cタイプ1と7の両方について、Session_Attributeオブジェクトには現在、次のフラグが定義されています[RSVP-TE]：
Local protection desired: 0x01
希望のローカル保護：0x01
This flag permits transit routers to use a local repair mechanism that may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit node may reroute traffic for fast service restoration.
このフラグにより、トランジットルーターは、明示的なルートオブジェクトに違反する可能性のあるローカル修理メカニズムを使用できます。隣接するダウンストリームリンクまたはノードで障害が検出されると、トランジットノードがトラフィックを迅速に復元するために再ルーティングする場合があります。
Label recording desired: 0x02
希望のラベル記録：0x02
This flag indicates that label information should be included when doing a route record.
このフラグは、ルートレコードを実行するときにラベル情報を含める必要があることを示しています。
SE Style desired: 0x04
SEスタイルが望ましい：0x04
This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. When requesting fast reroute, the head-end LSR SHOULD set this flag; this is not necessary for the path-specific method of the one-to-one backup method.
このフラグは、トンネルイングレスノードがこのトンネルを引き裂くことなく再ルーティングすることを選択できることを示しています。Tunnel Egressノードは、RESVメッセージで応答するときにSEスタイルを使用する必要があります。Fast Rerouteを要求するとき、ヘッドエンドLSRはこのフラグを設定する必要があります。これは、1対1のバックアップ方法のパス固有の方法には必要ありません。
The following new flags are defined:
次の新しいフラグが定義されています。
Bandwidth protection desired: 0x08
帯域幅保護が望ましい：0x08
This flag indicates to the PLRs along the protected LSP path that a backup path with a bandwidth guarantee is desired. The bandwidth to be guaranteed is that of the protected LSP, if no FAST_REROUTE object is included in the PATH message; if a FAST_REROUTE object is in the PATH message, then the bandwidth specified therein is to be guaranteed.
このフラグは、保護されたLSPパスに沿ったPLRに、帯域幅保証を備えたバックアップパスが必要であることを示しています。保証される帯域幅は、PATHメッセージにFAST_REROUTEオブジェクトが含まれていない場合、保護されたLSPの帯域幅です。fast_rerouteオブジェクトがパスメッセージにある場合、そこで指定された帯域幅が保証されます。
Node protection desired: 0x10
希望のノード保護：0x10
This flag indicates to the PLRs along a protected LSP path that a backup path that bypasses at least the next node of the protected LSP is desired.
このフラグは、保護されたLSPパスに沿ったPLRに、少なくとも保護されたLSPの次のノードをバイパスするバックアップパスが望ましいことを示しています。
To report whether bandwidth and/or node protection are provided as requested, we define two new flags in the RRO IPv4 sub-object.
要求に応じて帯域幅および/またはノード保護が提供されるかどうかを報告するために、RRO IPv4サブオブジェクトに2つの新しいフラグを定義します。
The RRO IPv4 and IPv6 address sub-objects currently have the following flags defined [RSVP-TE]:
RRO IPv4およびIPv6アドレスサブオブジェクトは現在、次のフラグが定義されている[RSVP-TE]：
Local protection available: 0x01
利用可能なローカル保護：0x01
Indicates that the link downstream of this node is protected via a local repair mechanism, which can be either one-to-one or facility backup.
このノードの下流のリンクがローカル修理メカニズムを介して保護されていることを示します。これは、1対1または施設のバックアップである可能性があります。
Local protection in use: 0x02
使用中のローカル保護：0x02
Indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over, or an outage of the neighboring node).
このトンネルを維持するために局所的な修復メカニズムが使用されていることを示します（通常、以前にルーティングされていたリンクの停止、または隣接するノードの停止に直面して）。
Two new flags are defined:
2つの新しいフラグが定義されています。
Bandwidth protection: 0x04
帯域幅保護：0x04
The PLR will set this bit when the protected LSP has a backup path that is guaranteed to provide the desired bandwidth that is specified in the FAST_REROUTE object or the bandwidth of the protected LSP, if no FAST_REROUTE object was included. The PLR may set this whenever the desired bandwidth is guaranteed; the PLR MUST set this flag when the desired bandwidth is guaranteed and the "bandwidth protection desired" flag was set in the SESSION_ATTRIBUTE object. If the requested bandwidth is not guaranteed, the PLR MUST NOT set this flag.
PLRは、保護されたLSPに、FAST_REROUTEオブジェクトまたは保護されたLSPの帯域幅で指定された目的の帯域幅を提供することが保証されているバックアップパスがある場合、FAST_REREROUTEオブジェクトが含まれていない場合、このビットを設定します。PLRは、目的の帯域幅が保証されるたびにこれを設定する場合があります。PLRは、目的の帯域幅が保証され、「帯域幅保護が望ましい」フラグがsession_attributeオブジェクトに設定された場合に、このフラグを設定する必要があります。要求された帯域幅が保証されていない場合、PLRはこのフラグを設定してはなりません。
Node protection: 0x08
ノード保護：0x08
The PLR will set this bit when the protected LSP has a backup path that provides protection against a failure of the next LSR along the protected LSP. The PLR may set this whenever node protection is provided by the protected LSP's backup path; the PLR MUST set this flag when the node protection is provided and the "node protection desired" flag was set in the SESSION_ATTRIBUTE object. If node protection is not provided, the PLR MUST NOT set this flag. Thus, if a PLR could only set up a link-protection backup path, the "Local protection available" bit will be set, but the "Node protection" bit will be cleared.
PLRは、保護されたLSPが保護されたLSPに沿った次のLSRの障害に対する保護を提供するバックアップパスを持っている場合、このビットを設定します。PLRは、保護されたLSPのバックアップパスによってノード保護が提供されるたびにこれを設定する場合があります。ノード保護が提供され、「ノード保護が望ましい」フラグがSession_Attributeオブジェクトに設定された場合、PLRはこのフラグを設定する必要があります。ノード保護が提供されていない場合、PLRはこのフラグを設定してはなりません。したがって、PLRがリンク保護バックアップパスのみを設定できた場合、「ローカル保護可能」ビットが設定されますが、「ノード保護」ビットはクリアされます。
The head-end of an LSP determines whether local protection should be requested for that LSP and which local protection method is desired for the protected LSP. The head-end also determines what constraints should be requested for the backup paths of a protected LSP.
LSPのヘッドエンドは、そのLSPに対して局所保護を要求すべきかどうか、保護されたLSPに対してどの局所保護方法が望ましいかを決定します。ヘッドエンドは、保護されたLSPのバックアップパスに対してどの制約を要求すべきかを決定します。
To indicate that an LSP should be locally protected, the head-end LSR MUST either set the "local protection desired" flag in the SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH message, or both. The "local protection desired" flag in the SESSION_ATTRIBUTE object SHOULD always be set. If a head-end LSR signals a FAST_REROUTE object, it MUST be stored for Path refreshes.
LSPをローカルで保護する必要があることを示すために、ヘッドエンドLSRは、session_attributeオブジェクトに「ローカル保護が望ましい」フラグを設定するか、パスメッセージまたはその両方にfast_rerouteオブジェクトを含める必要があります。session_attributeオブジェクトの「希望するローカル保護」フラグは常に設定する必要があります。ヘッドエンドLSRがFAST_REROUTEオブジェクトを信号する場合、パスリフレッシュのために保存する必要があります。
The head-end LSR of a protected LSP MUST set the "label recording desired" flag in the SESSION_ATTRIBUTE object. This facilitates the use of the facility backup method. If node protection is desired, the head-end LSR should set the "node protection desired" flag in the SESSION_ATTRIBUTE object; otherwise, this flag should be cleared. Similarly, if a guarantee of bandwidth protection is desired, then the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE object should be set; otherwise, this flag should be cleared. If the head-end LSR determines that control of the backup paths for the protected LSP is desired, then the LSR should include the FAST_REROUTE object. The PLRs will use the attribute filters, bandwidth, hop-limit, and priorities to determine the backup paths.
保護されたLSPのヘッドエンドLSRは、session_attributeオブジェクトに「希望のラベル記録が望ましい」フラグを設定する必要があります。これにより、施設のバックアップ方法の使用が容易になります。ノード保護が必要な場合、ヘッドエンドLSRは、session_attributeオブジェクトに「ノード保護が望む」フラグを設定する必要があります。それ以外の場合、このフラグをクリアする必要があります。同様に、帯域幅保護の保証が必要な場合、session_attributeオブジェクトの「帯域幅保護が望む」フラグを設定する必要があります。それ以外の場合、このフラグをクリアする必要があります。ヘッドエンドLSRが、保護されたLSPのバックアップパスの制御が望ましいと判断した場合、LSRにはfast_rerouteオブジェクトを含める必要があります。PLRは、属性フィルター、帯域幅、ホップリミット、および優先順位を使用して、バックアップパスを決定します。
If the head-end LSR desires that the one-to-one backup method be used for the protected LSP, then the head-end LSR should include a FAST_REROUTE object and set the "one-to-one backup desired" flag. If the head-end LSR desires that the protected LSP be protected via the facility backup method, then the head-end LSR should include a FAST_REROUTE object and set the "facility backup desired" flag. The lack of a FAST_REROUTE object, or having both these flags clear, should be treated by PLRs as a lack of preference. If both flags are set, a PLR may use either method or both.
ヘッドエンドLSRが1対1のバックアップメソッドを保護されたLSPに使用することを望む場合、ヘッドエンドLSRにはfast_rerouteオブジェクトを含めて、「1対1のバックアップが望む」フラグを設定する必要があります。ヘッドエンドLSRが、保護されたLSPが施設のバックアップ方法を介して保護されることを望んでいる場合、ヘッドエンドLSRにはfast_rerouteオブジェクトを含め、「施設バックアップが望む」フラグを設定する必要があります。Fast_rerouteオブジェクトの欠如、またはこれらの両方のフラグを明確にすることは、PLRによって好みの欠如として扱われるべきです。両方のフラグが設定されている場合、PLRはメソッドまたは両方を使用する場合があります。
The head-end LSR of a protected LSP MUST support the additional flags defined in Section 4.4 being set or clear in the RRO IPv4 and IPv6 sub-objects. The head-end LSR of a protected LSP MUST support the RRO Label sub-object.
保護されたLSPのヘッドエンドLSRは、RRO IPv4およびIPv6サブオブジェクトで設定またはクリアされているセクション4.4で定義されている追加のフラグをサポートする必要があります。保護されたLSPのヘッドエンドLSRは、RROラベルサブオブジェクトをサポートする必要があります。
If the head-end LSR of an LSP determines that local protection is newly desired, this SHOULD be signaled via make-before-break.
LSPのヘッドエンドLSRが、局所保護が新たに望まれていると判断した場合、これはブレイク前に通知する必要があります。
Every LSR along a protected LSP (except the egress) MUST follow the PLR behavior described in this document.
保護されたLSP（出口を除く）に沿ったすべてのLSRは、このドキュメントで説明されているPLRの動作に従う必要があります。
A PLR SHOULD support the FAST_REROUTE object, the "local protection desired", "label recording desired", "node protection desired", and "bandwidth protection desired" flags in the SESSION_ATTRIBUTE object, and the "local protection available", "local protection in use", "bandwidth protection", and "node protection" flags in the RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR object.
PLRは、fast_rerouteオブジェクト、「希望のローカル保護」、「希望のラベル記録」、「希望のノード保護」、および「帯域幅保護が希望する」フラグをサポートする必要があります。「、「帯域幅保護」、「帯域幅保護」、およびRRO IPv4およびIPv6サブオブジェクトの「ノード保護」フラグが使用されています。PLRは、迂回路をサポートする場合があります。
A PLR MUST consider an LSP to have asked for local protection if the "local protection desired" flag is set in the SESSION_ATTRIBUTE object and/or the FAST_REROUTE object is included. If the FAST_REROUTE object is included, a PLR SHOULD consider providing one-to-one protection if the "one-to-one desired" is set, and it SHOULD consider providing facility backup if the "facility backup desired" flag is set. If the "node protection desired" flag is set, the PLR SHOULD try to provide node protection; if this is not feasible, the PLR SHOULD then try to provide link protection. If the "bandwidth protection guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth guarantee; if this is not feasible, the PLR SHOULD then try to provide a backup without a guarantee of the full bandwidth.
PLRは、「ローカル保護が望む」フラグがsession_attributeオブジェクトに設定されている場合、および/またはfast_rerouteオブジェクトが含まれている場合、LSPがローカル保護を求めていることを検討する必要があります。FAST_REROUTEオブジェクトが含まれている場合、PLRは「1対1の目的」が設定されている場合は1対1の保護を提供することを検討する必要があり、「施設のバックアップが望む」フラグが設定されている場合、施設のバックアップを提供することを検討する必要があります。「ノード保護が希望する」フラグが設定されている場合、PLRはノード保護を提供しようとする必要があります。これが実行不可能な場合、PLRはリンク保護を提供しようとする必要があります。「帯域幅保護が保証された」フラグが設定されている場合、PLRは帯域幅保証を提供しようとする必要があります。これが実行不可能な場合、PLRは完全な帯域幅を保証せずにバックアップを提供しようとする必要があります。
The following treatment for the RRO IPv4 or IPv6 sub-object's flags must be followed if an RRO is included in the protected LSP's RESV message. Based on this additional information, the head-end may take appropriate actions.
RROが保護されたLSPのRESVメッセージに含まれている場合は、RRO IPv4またはIPv6サブオブジェクトのフラグの次の処理に従う必要があります。この追加情報に基づいて、ヘッドエンドは適切なアクションを実行する場合があります。
- Until a PLR has a backup path available, the PLR MUST clear the relevant four flags in the corresponding RRO IPv4 or IPv6 sub-object.
- PLRにバックアップパスが利用可能になるまで、PLRは、対応するRRO IPv4またはIPv6サブオブジェクトの関連する4つのフラグをクリアする必要があります。
- Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. If no established one-to-one backup LSP or bypass tunnel exists, or if the one-to-one LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear the "local protection available" flag in its IPv4 (or IPv6) address sub-object of the RRO and SHOULD send the updated RESV.
- PLRにバックアップパスが利用可能な場合はいつでも、PLRは「ローカル保護可能」フラグを設定する必要があります。1対1のバックアップLSPまたはバイパストンネルが確立されていない場合、または1対1のLSPとバイパストンネルが「ダウン」状態にある場合、PLRはIPv4の「ローカル保護利用可能」フラグをクリアする必要があります（またはIPv6）RROのサブオブジェクトをアドレスして、更新されたRESVを送信する必要があります。
- The PLR MUST clear the "local protection in use" flag unless it is actively redirecting traffic into the backup path instead of along the protected LSP.
- PLRは、保護されたLSPに沿ってではなくバックアップパスにトラフィックを積極的にリダイレクトしない限り、「使用中のローカル保護」フラグをクリアする必要があります。
- The PLR SHOULD also set the "node protection" flag if the backup path protects against the failure of the immediate downstream node, and, if the path does not, the PLR SHOULD clear the "node protection" flag. This MUST be done if the "node protection desired" flag was set in the SESSION_ATTRIBUTE object.
- また、PLRは、バックアップパスが即時のダウンストリームノードの障害から保護する場合、「ノード保護」フラグを設定する必要があり、パスがそうでない場合、PLRは「ノード保護」フラグをクリアする必要があります。これは、session_attributeオブジェクトに「希望のノード保護」フラグが設定されている場合に行う必要があります。
- The PLR SHOULD set the "bandwidth protection" flag if the backup path offers a bandwidth guarantee, and, if the path does not, the PLR SHOULD clear the "bandwidth protection" flag. This MUST be done if the "bandwidth protection desired" flag was set in the SESSION_ATTRIBUTE object.
- PLRは、バックアップパスが帯域幅保証を提供する場合、「帯域幅保護」フラグを設定する必要があり、パスがそうでない場合、PLRは「帯域幅保護」フラグをクリアする必要があります。これは、session_attributeオブジェクトに「帯域幅保護が希望する」フラグが設定された場合に行う必要があります。
A number of objectives must be met to obtain a satisfactory signaling solution. These are summarized as follows:
満足のいくシグナル伝達ソリューションを取得するには、多くの目的を満たす必要があります。これらは次のように要約されています。
1. Unambiguously and uniquely identifying backup paths.
1. バックアップパスを明確かつ一意に識別します。
2. Unambiguously associating protected LSPs with their backup paths.
2. 保護されたLSPをバックアップパスに明確に関連付けます。
3. Working with both global and non-global label spaces.
3. グローバルラベルと非グローバルラベルスペースの両方で作業しています。
4. Allowing merging of backup paths.
4. バックアップパスのマージを許可します。
5. Maintaining RSVP state during and after fail-over.
5. フェールオーバー中およびフェールオーバー後にRSVP状態を維持します。
LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects [RSVP-TE]. The relevant fields are as follows.
LSPトンネルは、セッションとsender_templateオブジェクト[RSVP-TE]の組み合わせによって識別されます。関連するフィールドは次のとおりです。
IPv4 (or IPv6) tunnel end point address
IPv4（またはIPv6）トンネルエンドポイントアドレス
IPv4 (or IPv6) address of the egress node for the tunnel.
トンネルの出力ノードのIPv4（またはIPv6）アドレス。
Tunnel ID
トンネルID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
セッションで使用される16ビット識別子は、トンネルの存続期間中に一定のままです。
Extended Tunnel ID
拡張トンネルID
A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION that remains constant over the life of the tunnel. Normally it is set to all zero. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IP address here as a globally unique identifier.
セッションで使用される32ビット（IPv4）または128ビット（IPv6）識別子は、トンネルの寿命にわたって一定のままです。通常、それはすべてゼロに設定されます。イングレスエグレスペアにセッションの範囲を狭めたいと考えているイングレスノードは、グローバルに一意の識別子としてIPアドレスをここに配置する可能性があります。
IPv4 (or IPv6) tunnel sender address
IPv4（またはIPv6）トンネル送信者アドレス
IPv4 (or IPv6) address for a sender node.
送信者ノードのIPv4（またはIPv6）アドレス。
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC, which can be changed to allow a sender to share resources with itself.
sender_templateおよびfilter_specで使用される16ビット識別子。これを変更して、送信者がそれ自体とリソースを共有できるようにすることができます。
The first three of these are in the SESSION object and are the basic identification for the tunnel. Setting the "Extended Tunnel ID" to an IP address of the head-end LSR allows the scope of the SESSION to be narrowed to only LSPs sent by that LSR. A backup LSP is considered part of the same session as its protected LSP; therefore these three cannot be varied.
これらの最初の3つはセッションオブジェクトにあり、トンネルの基本的な識別です。「拡張トンネルID」をヘッドエンドLSRのIPアドレスに設定すると、セッションの範囲をそのLSRが送信したLSPのみに絞り込むことができます。バックアップLSPは、保護されたLSPと同じセッションの一部と見なされます。したがって、これらの3つを変化させることはできません。
The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same SESSION may be protected and may take different routes; this is common when a tunnel is rerouted using make-before-break. A backup path must be clearly identified with its protected LSP to allow correct merging and state treatment. Therefore, a backup path must inherit its LSP ID from the associated protected LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE objects that could be varied between a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE.
最後の2つはsender_templateにあります。同じセッションの複数のLSPが保護され、異なるルートを取る場合があります。これは、ブレイク前にメイクを使用してトンネルが再ルーティングされる場合に一般的です。正しいマージと状態治療を可能にするために、保護されたLSPでバックアップパスを明確に識別する必要があります。したがって、バックアップパスは、関連する保護されたLSPからLSP IDを継承する必要があります。したがって、バックアップパスと保護されたLSPの間で変化する可能性のあるセッションとsender_templateオブジェクトの唯一のフィールドは、sender_templateの「IPv4（またはIPv6）トンネル送信者アドレス」です。
There are two different methods to uniquely identify a backup path, described below.
以下で説明するバックアップパスを一意に識別する2つの異なる方法があります。
In this approach, the SESSION object and the LSP_ID are copied from the protected LSP. The "IPv4 tunnel sender address" is set to an address of the PLR. If the head-end of a tunnel is also acting as the PLR, it MUST choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel.
このアプローチでは、セッションオブジェクトとLSP_IDが保護されたLSPからコピーされます。「IPv4トンネル送信者アドレス」は、PLRのアドレスに設定されています。トンネルのヘッドエンドもPLRとして作用している場合、元のLSPトンネルのsender_templateで使用されているものとは異なるIPアドレスを選択する必要があります。
When the sender template-specific approach is used, the protected LSPs and the backup paths SHOULD use the Shared Explicit (SE) style. This allows bandwidth sharing between multiple backup paths. The backup paths and the protected LSP MAY be merged by the Detour Merge Points, when the ERO from the MP to the egress is the same on each LSP to be merged, as specified in [RSVP-TE].
送信者テンプレート固有のアプローチを使用する場合、保護されたLSPとバックアップパスは、共有明示（SE）スタイルを使用する必要があります。これにより、複数のバックアップパス間で帯域幅を共有できます。バックアップパスと保護されたLSPは、[RSVP-TE]で指定されているように、MPから出口へのEROが各LSPでマージされる場合に同じである場合、迂回路のマージポイントによってマージされる場合があります。
In this approach, rather than vary the SESSION or SENDER_TEMPLATE objects, an implementation uses a new object, the DETOUR object, to distinguish between PATH messages for a backup path and the protected LSP.
このアプローチでは、セッションまたはsender_templateオブジェクトを変更するのではなく、実装は新しいオブジェクトである迂回オブジェクトを使用して、バックアップパスのパスメッセージと保護されたLSPを区別します。
Thus, the backup paths use the same SESSION and SENDER_TEMPLATE objects as the ones used in the protected LSP. The presence of a DETOUR object in Path messages signifies a backup path; the presence of a FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object indicates a protected LSP.
したがって、バックアップパスは、保護されたLSPで使用されているものと同じセッションとsender_templateオブジェクトを使用します。パスメッセージに迂回オブジェクトが存在することは、バックアップパスを意味します。fast_rerouteオブジェクトおよび/またはsession_attributeオブジェクトに「要求された」フラグの存在は、保護されたLSPを示します。
In the path message-specific approach, an LSR merges Path messages that are received with the same SESSION and SENDER_TEMPLATE objects and that also have the same next-hop object. Without this behavior, it would be impossible to associate the multiple RESV messages with the backup paths. However, this merging behavior reduces the total number of RSVP states inside the network at the expense of merging LSPs with different EROs.
パスメッセージ固有のアプローチでは、LSRは同じセッションとsender_templateオブジェクトで受信されるパスメッセージをマージします。この動作がなければ、複数のRESVメッセージをバックアップパスに関連付けることは不可能です。ただし、このマージの動作により、LSPを異なるEROSと統合することを犠牲にして、ネットワーク内のRSVP状態の総数が減少します。
Before a PLR can create a detour or a bypass tunnel, the desired explicit route must be determined. This can be done using a CSPF (Constraint-based Shortest Path First) computation. Before this CSPF computation, the following information must be collected at a PLR:
PLRが迂回路またはバイパストンネルを作成する前に、目的の明示的なルートを決定する必要があります。これは、CSPF（制約ベースの最短パス最初のパス）計算を使用して実行できます。このCSPF計算の前に、次の情報をPLRで収集する必要があります。
- The list of downstream nodes that the protected LSP passes through. This information is readily available from the RECORD_ROUTE objects during LSP setup. This information is also available from the ERO. However, if the ERO contains loose sub-objects, the ERO may not provide adequate information.
- 保護されたLSPが通過する下流ノードのリスト。この情報は、LSPセットアップ中にRecord_Routeオブジェクトから簡単に入手できます。この情報はEROからも入手できます。ただし、EROにゆるいサブオブジェクトが含まれている場合、EROは適切な情報を提供しない場合があります。
- The downstream links/nodes that we want to protect against. Once again, this information is learned from the RECORD_ROUTE objects. Whether node protection is desired is determined by the "node protection" flag in the SESSION_ATTRIBUTE object and local policy.
- 保護したい下流のリンク/ノード。繰り返しになりますが、この情報はrecord_routeオブジェクトから学習されます。ノード保護が必要かどうかは、Session_Attributeオブジェクトとローカルポリシーの「ノード保護」フラグによって決定されます。
- The upstream uni-directional links that the protected LSP passes through. This information is learned from the RECORD_ROUTE objects; it is only needed for setting up one-to-one protection. In the path-specific method, it is necessary to avoid the detour and the protected LSP sharing a common next-hop upstream of the failure. In the sender template-specific mode, this same restriction is necessary to avoid sharing bandwidth between the detour and its protected LSP, where that bandwidth has been reserved only once.
- 保護されたLSPが通過する上流の一方向リンク。この情報は、record_routeオブジェクトから学習されます。1対1の保護を設定するためにのみ必要です。パス固有の方法では、迂回路や保護されたLSPが障害の上流の共通の次のホップを共有することを避ける必要があります。Sender Template固有のモードでは、この同じ制限が、迂回路とその保護されたLSPの間の帯域幅を共有しないようにするために必要です。
- The link attribute filters to be applied. These are derived from the FAST_REROUTE object, if it is included in the PATH message, or from the SESSION_ATTRIBUTE object otherwise.
- リンク属性フィルターが適用されます。これらは、パスメッセージに含まれている場合、またはそれ以外の場合はsession_attributeオブジェクトに含まれている場合、fast_rerouteオブジェクトから派生します。
- The bandwidth to be used is found in the FAST_REROUTE object, if it is included in the PATH message, or in the SESSION_ATTRIBUTE object otherwise. Local policy may modify the bandwidth to be reserved.
- 使用する帯域幅は、パスメッセージに含まれている場合、またはそれ以外の場合はsession_attributeオブジェクトに含まれている場合、fast_rerouteオブジェクトにあります。ローカルポリシーは、帯域幅を留保するように変更する場合があります。
- The hop-limit, if a FAST_REROUTE object was included in the PATH message.
- fast_rerouteオブジェクトがパスメッセージに含まれている場合、ホップリミット。
When a CSPF algorithm is used to compute the backup route, the following constraints must be satisfied:
CSPFアルゴリズムを使用してバックアップルートを計算する場合、次の制約を満たす必要があります。
- For detour LSPs, the destination MUST be the tail-end of the protected LSP. For bypass tunnels (Section 7), the destination MUST be the address of the MP.
- 迂回路LSPの場合、目的地は保護されたLSPのテールエンドでなければなりません。バイパストンネル（セクション7）の場合、目的地はMPのアドレスでなければなりません。
- When one-to-one protection is set up by using the path-specific method, a detour MUST not traverse the upstream links of the protected LSP in the same direction. This prevents the possibility of early merging of the detour into the protected LSP. When one-to-one protection is set up using the sender-template-specific method, a detour should not traverse the upstream links of the protected LSP in the same direction. This prevents sharing the bandwidth between a protected LSP and its backup upstream of the failure where the bandwidth would be used twice in the event of a failure.
- パス固有の方法を使用して1対1の保護が設定されている場合、迂回路は、保護されたLSPの上流のリンクを同じ方向に横断してはなりません。これは、保護されたLSPに迂回路を早期にマージする可能性を防ぎます。Sender-Template固有の方法を使用して1対1の保護が設定されている場合、迂回路は、保護されたLSPの上流のリンクを同じ方向に通過してはなりません。これにより、保護されたLSPと、障害が発生した場合に帯域幅が2回使用される障害の上流のバックアップの間の帯域幅の共有を防ぎます。
- The backup LSP cannot traverse the downstream node and/or link whose failure is being protected against. Note that if the PLR is the penultimate hop, node protection is not possible, and only the downstream link can be avoided. The backup path may be computed to be SRLG disjoint from the downstream node and/or link being avoided.
- バックアップLSPは、障害が保護されている下流ノードやリンクを通過できません。PLRが最後から2番目のホップである場合、ノード保護は不可能であり、ダウンストリームリンクのみを回避できることに注意してください。バックアップパスは、下流ノードからのSRLGの分離および/またはリンクが回避されるように計算される場合があります。
- The backup path must satisfy the resource requirements of the protected LSP. This includes the link attribute filters, bandwidth, and hop limits determined from the FAST_REROUTE object and the SESSION_ATTRIBUTE object.
- バックアップパスは、保護されたLSPのリソース要件を満たす必要があります。これには、FAST_REROUTEオブジェクトとSESSION_ATTRIBUTEオブジェクトから決定されたリンク属性フィルター、帯域幅、およびホップ制限が含まれます。
If such computation succeeds, the PLR should attempt to establish a backup path. The PLR may schedule a re-computation at a later time to discover better paths that might have emerged. If for any reason, the PLR is unable to bring up a backup path, it must schedule a retry at a later time.
そのような計算が成功した場合、PLRはバックアップパスの確立を試みる必要があります。PLRは、後で再計算をスケジュールして、出現した可能性のあるより良いパスを発見する場合があります。何らかの理由で、PLRがバックアップパスを持ち出すことができない場合、後で再試行をスケジュールする必要があります。
Once a PLR has decided to protect an LSP locally with one-to-one backup and has identified the desired path, it signals for the detour.
PLRが1対1のバックアップでLSPをローカルに保護することを決定し、目的のパスを特定すると、迂回路のシグナルがあります。
The following describes the transformation to be performed upon the protected LSP's PATH message to create the detour LSP's PATH message.
以下は、保護されたLSPのパスメッセージで実行される変換について説明し、Detour LSPのパスメッセージを作成します。
- If the sender template-specific method is to be used, then the PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the SENDER_TEMPLATE to an address belonging to the PLR that is not the same as that used for the protected LSP. Additionally, the DETOUR object MAY be added to the PATH message.
- 送信者テンプレート固有の方法を使用する場合、PLRは、保護されたLSPに使用されているものと同じではないPLRに属するアドレスにsender_templateの「IPv4（またはIPv6）トンネル送信者アドレス」を変更する必要があります。。さらに、迂回路オブジェクトをパスメッセージに追加できます。
- If the path-specific method is to be used, then the PLR MUST add a DETOUR object to the PATH message.
- パス固有の方法を使用する場合、PLRはパスメッセージに迂回オブジェクトを追加する必要があります。
- The SESSION_ATTRIBUTE flags "Local protection desired", "Bandwidth protection desired", and "Node protection desired" MUST be cleared. The "Label recording desired" flag MAY be modified. If the Path Message contained a FAST_REROUTE object and the ERO is not completely strict, the Include-any, Exclude-any, and Include-all fields of the FAST_REROUTE object SHOULD be copied to the corresponding fields of the SESSION_ATTRIBUTE object.
- session_attributeフラグは、「希望するローカル保護」、「帯域幅保護が望ましい」、および「希望のノード保護」をクリアする必要があります。「希望のラベル記録」フラグが変更される場合があります。パスメッセージにFAST_REROUTEオブジェクトが含まれており、EROが完全に厳格ではない場合、FAST_REROUTEオブジェクトのinclude-Any、除外、および含まれるすべてのフィールドは、session_attributeオブジェクトの対応するフィールドにコピーする必要があります。
- If the protected LSP's Path message contained a FAST_REROUTE object, this object MUST be removed from the detour LSP's PATH message.
- 保護されたLSPのパスメッセージにFAST_REROUTEオブジェクトが含まれている場合、このオブジェクトはDetour LSPのパスメッセージから削除する必要があります。
- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. First, the PLR must remove all sub-objects preceding the first address belonging to the Merge Point. Then the PLR SHOULD add sub-objects corresponding to the desired backup path between the PLR and the MP.
- PLRは、出口に向かってexplicit_routeオブジェクトを生成する必要があります。まず、PLRは、マージポイントに属する最初のアドレスの前にあるすべてのサブオブジェクトを削除する必要があります。次に、PLRは、PLRとMPの間の目的のバックアップパスに対応するサブオブジェクトを追加する必要があります。
- The SENDER_TSPEC object SHOULD contain the bandwidth information from the received FAST_REROUTE object, if included in the protected LSP's PATH message.
- Sender_TSPECオブジェクトには、保護されたLSPのパスメッセージに含まれている場合、受信したFAST_REROUTEオブジェクトからの帯域幅情報を含める必要があります。
- The RSVP_HOP object containing one of the PLR's IP address.
- PLRのIPアドレスの1つを含むRSVP_HOPオブジェクト。
- The detour LSPs MUST use the same reservation style as the protected LSP. This must be correctly reflected in the SESSION_ATTRIBUTE object.
- 迂回路LSPは、保護されたLSPと同じ予約スタイルを使用する必要があります。これは、session_attributeオブジェクトに正しく反映する必要があります。
Detour LSPs operate like regular LSPs. Once a detour path is successfully computed and the detour LSP is established, the PLR need not compute detour routes again, unless (1) the contents of FAST_REROUTE have changed or (2) the downstream interface and/or the nexthop router for a protected LSP has changed. The PLR may recompute detour routes at any time.
Detour LSPは通常のLSPのように動作します。迂回パスが正常に計算され、迂回路LSPが確立されると、（1）fast_rerouteの内容が変更されていない場合、または（2）保護されたLSPのダウンストリームインターフェイスおよび/またはNexthopルーターが変更されていない限り、PLRは迂回ルートを再度計算する必要はありません。変更されました。PLRは、いつでも迂回ルートを再計算する場合があります。
If the sender template-specific method is used, it is possible to do make-before-break with detour LSPs. This is done using two different IP addresses belonging to the PLR (which were not used in the SENDER_TEMPLATE of the protected LSP). If the current detour LSP uses the first IP address in its SENDER_TEMPLATE, then the new detour LSP should be signaled by using the second IP address in its SENDER_TEMPLATE. Once the new detour LSP has been created, the current detour LSP can be torn down. By alternating the use of these IP addresses, the current and new detour LSPs will have different SENDER_TEMPLATES and, thus, different state in the downstream LSRs.
送信者テンプレート固有の方法が使用される場合、迂回路LSPでブレイク前に行うことができます。これは、PLRに属する2つの異なるIPアドレス（保護されたLSPのsender_templateで使用されなかった）を使用して行われます。現在の迂回LSPがsender_templateで最初のIPアドレスを使用している場合、sender_templateの2番目のIPアドレスを使用して、新しい迂回LSPを信号する必要があります。新しい迂回路LSPが作成されると、現在の迂回路LSPを取り壊すことができます。これらのIPアドレスの使用を交互に使用することにより、現在および新しい迂回路LSPは異なるsender_templatesを持ち、したがって、下流のLSRで異なる状態になります。
This make-before-break mechanism, which changes the PLR IP address in the DETOUR object instead, is not feasible with the path-specific method, as the PATH messages for new and current detour LSPs may be merged if they share a common next-hop.
代わりに迂回オブジェクトのPLR IPアドレスを変更するこのブレイク前のメカニズムは、新しい迂回路LSPのパスメッセージが共通の次のものを共有する場合にマージされる可能性があるため、パス固有の方法では実行不可能です - ホップ。
LSRs must process the detour LSPs independently of the protected LSPs to avoid triggering the LSP loop detection procedure described in [RSVP-TE].
LSRは、[RSVP-TE]で説明されているLSPループ検出手順のトリガーを避けるために、保護されたLSPとは無関係に迂回LSPを処理する必要があります。
The PLR MUST not mix the messages for the protected and the detour LSPs. When a PLR receives Resv, ResvTear, and PathErr messages from the downstream detour destination, the messages MUST not be forwarded upstream. Similarly, when a PLR receives ResvErr and ResvConf messages from a protected LSP, it MUST not propagate them onto the associated detour LSP.
PLRは、保護されたLSPと迂回路のメッセージを混ぜてはなりません。PLRがRESV、RESVTEAR、およびPatherRメッセージを下流の迂回宛ての目的地から受信した場合、メッセージを上流に転送してはなりません。同様に、PLRが保護されたLSPからRESVERRおよびRESVCONFメッセージを受信した場合、関連するDetour LSPに伝播してはなりません。
A session tear-down request is normally originated by the sender via PathTear messages. When a PLR node receives a PathTear message from upstream, it MUST delete both the protected and the detour LSPs. The PathTear messages MUST propagate to both protected and detour LSPs. During error conditions, the LSRs may send ResvTear messages to fix problems on the failing path. When a PLR node receives the ResvTear messages from downstream for a protected LSP, as long as a detour is up, the ResvTear messages MUST not be sent further upstream. PathErrs should be treated similarly.
通常、セッションの引き裂き要求は、PathTearメッセージを介して送信者によって発信されます。PLRノードが上流からPATHTEARメッセージを受信すると、保護されたLSPと迂回路LSPの両方を削除する必要があります。PathTearメッセージは、保護されたLSPと迂回路の両方に伝播する必要があります。エラー条件中、LSRSはresvtearメッセージを送信して、障害パスの問題を修正する場合があります。PLRノードが保護されたLSPに対して下流からRESVTEARメッセージを受信した場合、迂回路がアップしている限り、RESVTEARメッセージをさらに上流に送信する必要はありません。Patherrsも同様に扱う必要があります。
When the PLR detects a failure on the protected LSP, the PLR MUST rapidly switch packets to the protected LSP's backup LSP instead of to the protected LSP's normal out-segment. The goal of this method is to effect the redirection within 10s of milliseconds.
PLRが保護されたLSPの障害を検出する場合、PLRは保護されたLSPの通常のアウトセグメントではなく、保護されたLSPのバックアップLSPに迅速にパケットを切り替える必要があります。この方法の目標は、ミリ秒の10秒以内にリダイレクトを実施することです。
L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | | L44
| L47 |
R6----------------R7
Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4]
Example 3. Redirect to Detour
例3.迂回路にリダイレクトします
In Example 3, if the link [R2->R3] fails, R2 would do the following. Any traffic received on link [R1->R2] with label L32 would be sent on link [R2->R6] with label L46 (along the detour LSP) instead of on link [R3->R4] with label L34 (along the protected LSP). The merge point R4 would recognize that packets received on link [R7->R4] with label L44 should be sent on link [R4->R5] with label L35 and that they should be merged with the protected LSP.
例3では、リンク[R2-> R3]が失敗した場合、R2は次のことを行います。ラベルL32を含むリンク[R1-> R2]で受信したトラフィックは、ラベルL46（R3-> R4]ではなく、ラベルL46（Detour LSPに沿って）でリンク[R2-> R6]でリンク[R2-> R6]に送信されます。保護されたLSP）。マージポイントR4は、リンク[R7-> R4]で受信したパケットをラベルL44で受信したパケットをラベルL35とリンク[R4-> R5]に送信する必要があり、保護されたLSPと統合する必要があることを認識します。
A PLR may use one or more bypass tunnels to protect against the failure of a link and/or a node. These bypass tunnels may be set up in advance or may be dynamically created as new protected LSPs are signaled.
PLRは、1つ以上のバイパストンネルを使用して、リンクおよび/またはノードの障害から保護する場合があります。これらのバイパストンネルは、事前にセットアップされるか、新しい保護されたLSPが通知されると動的に作成される場合があります。
To support facility backup, the PLR must determine a label that will indicate to the MP that packets received with that label should be switched along the protected LSP. This can be done without explicitly signaling the backup path if the MP uses a label space global to that LSR.
施設のバックアップをサポートするには、PLRは、そのラベルで受け取ったパケットを保護されたLSPに沿って切り替える必要があることをMPに示すラベルを決定する必要があります。これは、MPがそのLSRにグローバルなラベルスペースを使用している場合、バックアップパスを明示的に信号することなく実行できます。
As described in Section 6, the head-end LSR MUST set the "label recording requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting local protection. This will cause (as specified in [RSVP-TE]) all LSRs to record their INBOUND labels and to note via a flag whether the label is global to the LSR. Thus, when a protected LSP is first signaled through a PLR, the PLR can examine the RRO in the Resv message and learn about the incoming labels that are used by all downstream nodes for this LSP
セクション6で説明されているように、ヘッドエンドLSRは、ローカル保護を要求するLSPの「session_attributeオブジェクトの「要求されたラベル録音」フラグを設定する必要があります。これにより、（[RSVP-TE]で指定されているように）すべてのLSRがインバウンドラベルを記録し、ラベルがLSRにグローバルであるかどうかをフラグを介して記録します。したがって、保護されたLSPが最初にPLRを介してシグナルにされると、PLRはRESVメッセージのRROを調べ、このLSPのすべての下流ノードで使用される入っているラベルについて学ぶことができます
When MPs use per-interface label spaces, the PLR must send Path messages (for each protected LSP using a bypass tunnel) via that bypass tunnel prior to the failure in order to discover the appropriate MP label. The signaling procedures for this are in Section 6.4.3 below.
MPがインターフェイスごとのラベルスペースを使用する場合、PLRは、適切なMPラベルを発見するために、障害の前にそのバイパストンネルを介してパスメッセージ（バイパストンネルを使用して保護されたLSPごとに）を送信する必要があります。これのシグナル伝達手順は、以下のセクション6.4.3にあります。
A PLR that determines to use facility-backup to protect a given LSP should select a bypass tunnel to use, taking into account whether node protection is to be provided, what bandwidth was requested, whether a bandwidth guarantee is desired, and what link attribute filters were specified in the FAST_REROUTE object. The selection of a bypass tunnel for a protected LSP is performed by the PLR when the LSP is first set up.
特定のLSPを保護するために施設のバックアップを使用することを決定するPLRは、ノード保護が提供されるかどうか、どの帯域幅が要求されたか、帯域幅保証が望ましいかどうか、およびリンク属性フィルターを考慮して、使用するバイパストンネルを選択する必要があります。fast_rerouteオブジェクトで指定されました。保護されたLSP用のバイパストンネルの選択は、LSPが最初にセットアップされたときにPLRによって実行されます。
When the PLR detects a link or/and node failure condition, it has to reroute the data traffic onto the bypass tunnel and to start sending the control traffic for the protected LSP onto the bypass tunnel.
PLRがリンクまたは/およびノードの故障条件を検出すると、データトラフィックをバイパストンネルに再ルーティングし、保護されたLSPの制御トラフィックの送信をバイパストンネルに送信し始めなければなりません。
The backup tunnel is identified by using the sender template-specific method. The procedures to follow are similar to those described in Section 6.3.
バックアップトンネルは、送信者テンプレート固有の方法を使用して識別されます。従うべき手順は、セクション6.3に記載されている手順に似ています。
- The SESSION is unchanged.
- セッションは変更されていません。
- The SESSION_ATTRIBUTE is unchanged except as follows: The "Local protection desired", "Bandwidth protection desired", and "Node protection desired" flags SHOULD be cleared. The "Label recording desired" MAY be modified.
- 次のようにセッション_Attributeは、次の場合を除き、変更されていません。「希望するローカル保護」、「帯域幅保護が望ましい」、「希望のノード保護」フラグをクリアする必要があります。「希望のラベル記録」が変更される場合があります。
- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE is set to an address belonging to the PLR.
- sender_templateのIPv4（またはIPv6）トンネル送信者アドレスは、PLRに属するアドレスに設定されています。
- The RSVP_HOP object MUST contain an IP source address belonging to the PLR. Consequently, the MP will send messages back to the PLR with that IP address as the destination.
- RSVP_HOPオブジェクトには、PLRに属するIPソースアドレスを含める必要があります。その結果、MPはそのIPアドレスが宛先としてPLRにメッセージを送り返します。
- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. Detailed ERO processing is described below.
- PLRは、出口に向かってexplicit_routeオブジェクトを生成する必要があります。詳細なERO処理を以下に説明します。
- The RRO object may have to be updated as described in Section 6.5.
- RROオブジェクトは、セクション6.5で説明されているように更新する必要がある場合があります。
The PLR sends Path, PathTear, and ResvConf messages via the backup tunnel. The MP sends Resv, ResvTear, and PathErr messages by sending them directly to the address in the RSVP_HOP object, as specified in [RSVP].
PLRは、バックアップトンネルを介してパス、PathTear、およびRESVCONFメッセージを送信します。MPは、[RSVP]で指定されているように、RSVP_HOPオブジェクトのアドレスに直接送信することにより、RESV、RESVTEAR、およびPATHERRメッセージを送信します。
If it is necessary to signal the backup prior to failure to determine the MP label to use, then the same Path message is sent. In this case, the PLR SHOULD continue to send Path messages for the protected LSP along the normal route. PathTear messages should be duplicated, with one sent along the normal route and one sent through the bypass tunnel. The MP should duplicate the Resv and ResvTear messages and send them to both the PLR and the LSR indicated by the protected LSP's RSVP_HOP object.
MPラベルの使用の決定に失敗する前にバックアップに信号を送信する必要がある場合は、同じパスメッセージが送信されます。この場合、PLRは、通常のルートに沿って保護されたLSPのパスメッセージを引き続き送信する必要があります。PathTearメッセージは複製する必要があり、通常のルートに沿って送信され、バイパストンネルを通って送信されます。MPは、RESVとRESVTEARメッセージを複製し、保護されたLSPのRSVP_HOPオブジェクトで示されるPLRとLSRの両方に送信する必要があります。
Procedures for ERO processing are described in [RSVP-TE]. This section describes additional ERO update procedures for Path messages that are sent over bypass tunnels. If normal ERO processing rules were followed, the Merge Point would examine the first sub-object and likely reject it (Bad initial sub-object). This is because the unmodified ERO might contain the IP address of a bypassed node (in the case of a NNHOP Bypass Tunnel) or of an interface that is currently down (in the case of a NHOP Backup Tunnel). For this reason, the PLR invokes the following ERO procedures before sending a Path message via a bypass tunnel.
ERO処理の手順は[RSVP-TE]で説明されています。このセクションでは、バイパストンネルを介して送信されるパスメッセージの追加のERO更新手順について説明します。通常のERO処理ルールが守られた場合、マージポイントは最初のサブオブジェクトを調べ、おそらくそれを拒否します（悪い初期サブオブジェクト）。これは、変更されていないEROに、バイパスノード（NNHOPバイパストンネルの場合）または現在ダウンしている（NHOPバックアップトンネルの場合）のインターフェイスのIPアドレスが含まれている可能性があるためです。このため、PLRは、バイパストンネルを介してパスメッセージを送信する前に、次のERO手順を呼び出します。
Sub-objects belonging to abstract nodes that precede the Merge Point are removed, along with the first sub-object belonging to the MP. A sub-object identifying the Backup Tunnel destination is then added.
マージポイントの前にある抽象ノードに属するサブオブジェクトは、MPに属する最初のサブオブジェクトとともに削除されます。バックアップトンネルの宛先を識別するサブオブジェクトが追加されます。
More specifically, the PLR MUST:
より具体的には、PLRは次のとおりです。
- remove all the sub-objects proceeding the first address belonging to the MP, and
- MPに属する最初の住所を進めるすべてのサブオブジェクトを削除し、
- replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.)
- この最初のMPアドレスをMPのIPアドレスに置き換えます。（これは、削除されたばかりの同じアドレスである可能性があることに注意してください。）
In addition to the method-specific signaling and packet treatment, there is common signaling that should be followed.
メソッド固有のシグナル伝達とパケット処理に加えて、従うべき一般的なシグナル伝達があります。
During fast reroute, for each protected LSP containing an RRO object, the PLR obtains the RRO from the protected LSP's stored RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted into the RRO by setting the "Local protection in use" and "Local Protection Available" flags.
Fast Reroute中、RROオブジェクトを含む保護された各LSPについて、PLRは保護されたLSPの保存されたRESVからRROを取得します。PLRは、「使用中のローカル保護」および「ローカル保護可能」フラグを設定することにより、RROに挿入されたIPv4またはIPv6サブオブジェクトを更新する必要があります。
In many situations, the route used during local repair will be less than optimal. The purpose of local repair is to keep high priority and loss-sensitive traffic flowing while a more optimal re-routing of the tunnel can be effected by the head-end of the tunnel. Thus, the head-end has to know of the failure so that it may re-signal an optimal LSP.
多くの状況では、ローカル修理中に使用されるルートは最適ではありません。現地の修理の目的は、優先度と損失に敏感なトラフィックを流れることですが、トンネルのより最適な再ルーティングは、トンネルのヘッドエンドによって行われます。したがって、ヘッドエンドは障害を知る必要があるため、最適なLSPを再指定する可能性があります。
To provide this notification, the PLR SHOULD send a Path Error message with error code of "Notify" (Error code = 25) and an error value field of ss00 cccc cccc cccc, where ss=00 and the sub-code = 3 ("Tunnel locally repaired") (see [RSVP-TE]).
この通知を提供するには、PLRは、「通知」（エラーコード= 25）のエラーコードとSS00 CCCC CCCC CCCCのエラー値フィールドを含むパスエラーメッセージを送信する必要があります。ここで、SS = 00およびサブコード= 3（ "局所的に修復されたトンネル "）（[rsvp-te]を参照）。
Additionally, a head-end may detect that an LSP has to be moved to a more optimal path by noticing failures reported via the IGP. Note that in the case of inter-area TE LSP (TE LSP spanning areas), the head-end LSR will have to rely exclusively on Path Error messages to be informed of failures in another area.
さらに、ヘッドエンドでは、IGPを介して報告された障害に気付くことにより、LSPをより最適なパスに移動する必要があることを検出する場合があります。Inter-Areeate LSP（TE LSPスパニングエリア）の場合、ヘッドエンドLSRは、別の領域の障害を通知するためにパスエラーメッセージのみに依存する必要があることに注意してください。
Upon a failure event, a protected TE LSP is locally repaired by the PLR. There are two basic strategies for restoring the TE LSP to a full working path.
障害イベントの場合、保護されたTE LSPがPLRによって局所的に修復されます。TE LSPを完全な作業経路に復元するための2つの基本的な戦略があります。
- Global revertive mode: The head-end LSR of each tunnel is responsible for reoptimizing the TE LSPs that used the failed resource. There are several potential reoptimization triggers: RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and timers. Note that this re-optimization process may proceed as soon as the failure is detected. It is not tied to the restoration of the failed resource.
- グローバル回復モード：各トンネルのヘッドエンドLSRは、故障したリソースを使用したTE LSPを再最適化する責任があります。RSVPエラーメッセージ、OSPF LSAまたはISIS LSPの検査、およびタイマーなど、いくつかの潜在的な再最適化トリガーがあります。この再最適化プロセスは、障害が検出されるとすぐに進行する可能性があることに注意してください。失敗したリソースの復元に結び付けられていません。
- Local revertive mode: Upon detecting that the resource is restored, the PLR re-signals each of the TE LSPs that used to be routed over the restored resource. Every TE LSP successfully re-signaled along the restored resource is switched back.
- ローカルリバートモード：リソースが復元されていることを検出すると、PLRは復元されたリソースを介してルーティングされていたテルプスのそれぞれを再署名します。すべてのTE LSPは、復元されたリソースに沿って再署名された正常に切り替えられます。
There are several circumstances in which a local revertive mode might not be desirable. In the case of resource flapping (not an uncommon failure type), this could generate multiple traffic disruptions. Therefore, in the local revertive mode, the PLR should implement a means to dampen the re-signaling process in order to limit potential disruptions due to flapping.
ローカルリバートモードが望ましくない可能性のあるいくつかの状況があります。リソースフラッピングの場合（珍しい故障タイプではありません）、これにより複数のトラフィックの混乱が生じる可能性があります。したがって、ローカルリバートモードでは、PLRは、羽ばたきによる潜在的な混乱を制限するために、再署名プロセスを減衰させる手段を実装する必要があります。
In the local revertive mode, any TE LSP will be switched back, without any distinction, whereas in the global revertive mode, the decision to reuse the restored resource is made by the head-end LSR based on the TE LSP attributes. When the head-end learns of the failure, it may reoptimize the protected LSP tunnel along a different and more optimal path, as it has a more complete view of the resources and TE LSP constraints. This means that the old LSP that has been reverted to may no longer be optimal. Note that in the case of inter-area LSP, where the TE LSP path computation might be done on some Path Computation Element, the reoptimization process can still be triggered on the Head-End LSP. The local revertive mode is optional.
ローカルリバートモードでは、任意のTE LSPが区別せずに切り替えられますが、グローバルリバートモードでは、復元されたリソースを再利用する決定は、TE LSP属性に基づいてヘッドエンドLSRによって行われます。ヘッドエンドが障害を知ったとき、リソースとTE LSPの制約をより完全に把握しているため、異なる最適なパスに沿って保護されたLSPトンネルを再現する可能性があります。これは、戻ってきた古いLSPが最適ではなくなる可能性があることを意味します。TE LSPパス計算が何らかのパス計算要素で行われる可能性がある場合、AREA間LSPの場合、再発現プロセスはヘッドエンドLSPで引き起こされる可能性があることに注意してください。ローカルリバートモードはオプションです。
However, there are circumstances in which the head-end does not have the ability to reroute the TE LSP (e.g., if the protected LSP is pinned down, as may be desirable if the paths are determined by using an off-line optimization tool), or if the head-end does not have the complete TE topology information (depending on the path computation scenario). In those cases, the local revertive mode might be an interesting option.
ただし、ヘッドエンドにTE LSPを再ルーティングする能力がない状況があります（たとえば、保護されたLSPがピン留めされている場合、オフライン最適化ツールを使用してパスが決定される場合に望ましい場合があります）、または、ヘッドエンドに完全なTEトポロジー情報がない場合（パス計算シナリオに応じて）。そのような場合、ローカルリバートモードは興味深い選択肢かもしれません。
The globally revertive mode SHOULD always be used. Note that a link or node "failure" may be due to the facility being permanently taken out of service. Local revertive mode is optional. When used in combination, the global mode may rely solely on timers to do the reoptimization. When local revertive mode is not used, head-end LSRs SHOULD react to RSVP error messages and/or IGP indications in order to make a timely response.
グローバルに戻るモードは常に使用する必要があります。リンクまたはノードの「障害」は、施設が恒久的に使用されていないためである可能性があることに注意してください。ローカルリバートモードはオプションです。組み合わせて使用すると、グローバルモードはタイマーのみに依存して再最適化を行うことができます。ローカルリバートモードを使用しない場合、ヘッドエンドLSRは、タイムリーな応答を行うために、RSVPエラーメッセージおよび/またはIGP表示に反応する必要があります。
Interoperability: If a PLR is configured with the local revertive mode but the MP is not, any attempt from the PLR to resignal the TE LSP over the restored resource will fail, as the MP will not send any Resv message. The PLR will still refresh the TE LSP over the backup tunnel. The TE LSP will not revert to the restored resource; instead, it will continue to use the backup until it is re-optimized.
相互運用性：PLRがローカルリバートモードで構成されているが、MPがない場合、MPがRESVメッセージを送信しないため、復元されたリソース上でTE LSPを辞任するPLRからの試みは失敗します。PLRは、バックアップトンネル上でTE LSPを更新します。TE LSPは復元されたリソースに戻りません。代わりに、再最適化されるまでバックアップを使用し続けます。
An LSR is a Merge Point if it receives the Path message for a protected LSP and one or more messages for a backup LSP that is merged into that protected LSP. In the one-to-one backup method, the LSR is aware that it is a merge node prior to failure. In the facility backup method, the LSR may not know that it is a Merge Point until a failure occurs and it receives a backup LSP's Path message. Therefore, an LSR that is on the path of a protected LSP SHOULD always assume that it is a merge point.
LSRは、保護されたLSPのパスメッセージと、その保護されたLSPにマージされたバックアップLSPの1つ以上のメッセージを受信した場合、マージポイントです。1対1のバックアップ方法では、LSRは障害前のマージノードであることを認識しています。施設のバックアップ方法では、LSRは、障害が発生し、バックアップLSPのパスメッセージを受信するまでマージポイントであることを知らない場合があります。したがって、保護されたLSPの経路にあるLSRは、常にそれがマージポイントであると仮定する必要があります。
When a MP receives a backup LSP's Path message through a bypass tunnel, the Send_TTL in the Common Header may not match the TTL of the IP packet within which the Path message was transported. This is expected behavior.
MPがバイパストンネルを介してバックアップLSPのパスメッセージを受信した場合、共通ヘッダーのsend_ttlは、パスメッセージが輸送されたIPパケットのTTLと一致しない場合があります。これは予想される動作です。
There are two circumstances in which a Merge Point will receive Path messages for a backup path prior to failure. In the first case, if a PLR is providing local protection via the one-to-one backup method, the detour will be signaled and must be properly handled by the MP.
マージポイントが障害の前にバックアップパスのパスメッセージを受信する2つの状況があります。最初のケースでは、PLRが1対1のバックアップメソッドを介してローカル保護を提供している場合、迂回路が信号を受け、MPによって適切に処理される必要があります。
In this case, the backup LSP may be signaled via the sender template-specific method or via the path-specific method.
この場合、バックアップLSPは、送信者テンプレート固有のメソッドまたはパス固有の方法を介してシグナル伝達される場合があります。
In the second case, if the Merge Point does not provide labels global to the MP and record them in a Label sub-object of the RRO, or if the PLR does not use such recorded information, the PLR may signal the backup path as described in Section 6.4.1. This will determine the label to use if the PLR is providing protection according to the facility backup method. In this case, the backup LSP is signaled via the sender template-specific method.
2番目のケースでは、マージポイントがMPにグローバルを提供し、RROのラベルサブオブジェクトにそれらを記録しない場合、またはPLRがそのような記録された情報を使用しない場合、PLRは記載されているようにバックアップパスを信号する場合がありますセクション6.4.1で。これにより、PLRが施設のバックアップ方法に従って保護を提供している場合に使用するラベルが決定されます。この場合、バックアップLSPは、送信者テンプレート固有の方法を介してシグナル伝えられます。
The reception of a backup LSP's path message does not indicate that a failure has occurred or that the incoming protected LSP will no longer be used.
バックアップLSPのパスメッセージの受信は、障害が発生したこと、または入っている保護されたLSPがもはや使用されないことを示していません。
An LSR may receive multiple Path messages for one or more backup LSPs and, possibly, for the protected LSP. Each of these Path messages will have a different SENDER_TEMPLATE. The protected LSP can be recognized because it will include the FAST_REROUTE object or have the "local protection desired" flag set in the SESSION_ATTRIBUTE object, or both.
LSRは、1つまたは複数のバックアップLSPの複数のパスメッセージを受信し、場合によっては保護されたLSPに対して受信する場合があります。これらのパスメッセージのそれぞれには、異なるsender_templateがあります。保護されたLSPは、fast_rerouteオブジェクトを含むか、session_attributeオブジェクト、またはその両方に「ローカル保護が望ましい」フラグを設定するため、認識できます。
If the outgoing interface and next-hop LSR are the same, then the Path messages are eligible for merging. Similarly to the specification in [RSVP-TE] for merging of RESV messages, only Path messages whose ERO from that LSR to the egress is the same can be merged. If merging occurs and one of the Path messages merged was for the protected LSP, then the final Path message to be sent MUST be that of the protected LSP. This merges the backup LSPs into the protected LSP at that LSR. Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically.
発信インターフェイスと次のホップLSRが同じ場合、パスメッセージはマージする資格があります。RESVメッセージのマージの[RSVP-TE]の仕様と同様に、そのLSRから出口へのEROが同じであると同じパスメッセージのみをマージできます。マージが発生し、マージされたパスメッセージの1つが保護されたLSPの場合、送信される最終的なパスメッセージは保護されたLSPのメッセージでなければなりません。これにより、バックアップLSPがそのLSRの保護されたLSPにマージされます。最終的なパスメッセージが識別されると、MPは定期的に下流に更新し始めなければなりません。
If merging occurs and all the Path messages were for backup LSPs, then the DETOUR object, if any, should be altered as specified in Section 8.1
マージが発生し、すべてのパスメッセージがバックアップLSPの場合、セクション8.1で指定されているように迂回オブジェクトを変更する必要があります。
An LSR (that is, an MP) may receive multiple Path messages from different interfaces with identical SESSION and SENDER_TEMPLATE objects. In this case, Path state merging is REQUIRED. The merging rule is as follows:
LSR（つまり、MP）は、同じセッションとsender_templateオブジェクトを持つ異なるインターフェイスから複数のパスメッセージを受信する場合があります。この場合、パス状態のマージが必要です。マージルールは次のとおりです。
If all Path messages have neither a FAST_REROUTE nor a DETOUR object, or if the MP is the egress of the LSP, no merging is required. The messages are processed according to [RSVP-TE].
すべてのパスメッセージにFAST_REROUTEも迂回オブジェクトもない場合、またはMPがLSPの出口である場合、マージは必要ありません。メッセージは[RSVP-TE]に従って処理されます。
Otherwise, the MP MUST record the Path state and the incoming interface. If the Path messages do not share an outgoing interface and a next-hop LSR, the MP MUST consider them to be independent LSPs and MUST NOT merge them.
それ以外の場合、MPはパス状態と着信インターフェイスを記録する必要があります。パスメッセージが発信インターフェイスと次のホップLSRを共有しない場合、MPはそれらを独立したLSPであると考える必要があり、それらをマージしてはなりません。
For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs the following procedure to create a Path message to forward downstream.
同じ発信インターフェイスと次のホップLSRを共有するすべてのパスメッセージについて、MPは次の手順を実行して、下流に進むパスメッセージを作成します。
1. If one or more of the Path messages is for the protected LSP (a protected LSP is one originated from this node, or with the FAST_REROUTE object, or without the DETOUR object), one of these must become the chosen Path message. There could be more than one; in that case, which one to forward is a local decision. Quit.
1. 1つ以上のパスメッセージが保護されたLSP用である場合（保護されたLSPは、このノードから発信されるもの、またはFAST_REROUTEオブジェクトを使用して、または迂回オブジェクトを使用しない場合、これらの1つが選択されたパスメッセージになる必要があります。複数ある可能性があります。その場合、それは地元の決定です。やめる。
2. From the remaining set of Detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid.
2. 残りの迂回路メッセージのセットから、他の人が避けたいノードを横断するものを考慮することから排除します。
3. If several still remain, which one to forward is a local decision. If none remain, then the MP MAY try to find a new route that avoids all nodes that merging Detour Paths want to avoid; it will forward a Path message with that ERO.
3. まだいくつか残っている場合、それはローカルな決定です。何も残っていない場合、MPは、迂回路の融合を避けたいすべてのノードを回避する新しいルートを見つけようとするかもしれません。そのEROでパスメッセージを転送します。
Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservations on the outgoing link, any merging should be considered to have occurred before bandwidth is reserved. Thus, even though Fixed Filter style is specified, multiple detours and/or their protected LSP (which are to be merged due to sharing an outgoing interface and next-hop LSR) will reserve only the bandwidth of the final Path message on that outgoing interface.
最終的なパスメッセージが識別されると、MPは定期的に下流に更新し始めなければなりません。他のLSPは、このノードでマージされていると見なされます。発信リンクの帯域幅の予約の場合、帯域幅が予約される前にマージが発生したと見なされるべきです。したがって、固定フィルタースタイルが指定されていますが、複数の迂回路および/または保護されたLSP（発信インターフェイスと次のホップLSRを共有するためにマージされます）は、その発信インターフェイスの最終パスメッセージの帯域幅のみを予約します。。
If no merged Path message can be constructed, the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded but it traverses nodes that some detours want to avoid, PathErrs SHOULD be sent in response to those detour Paths which cannot merge.
マージされたパスメッセージを作成できない場合、MPは最近受け取った迂回路メッセージに応じてPatherrを送信する必要があります。保護されたパスが転送されるように選択されているが、一部の迂回路を避けたいノードを横断する場合、マージできない迂回路に応じてpatherrsを送信する必要があります。
R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6
Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6]
Example 4. Path Message Merging
例4.パスメッセージのマージ
In Example 4, R8 will receive Path messages that have the same SESSION and SENDER_TEMPLATE from detours for R2 and R3. During merging at R8, because detour R3 has a shorter ERO path length (that is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as the final LSP and will only propagate its Path messages downstream. Upon receiving a Resv (or a ResvTear) message, R8 must relay the messages toward both R2 and R3.
例4では、R8はR2とR3の迂回路から同じセッションとsender_templateを持つパスメッセージを受信します。R8でのマージ中に、迂回R3のEROパスの長さが短い（つまり、EROは[R9-> R5-> R6]、パスの長さは3）ため、R8は最終LSPとして選択し、そのみを伝播します。下流のパスメッセージ。RESV（またはRESVTEAR）メッセージを受信すると、R8はR2とR3の両方に向けてメッセージを中継する必要があります。
R5 has to merge as well, and it will select the main LSP, since it has the FAST_REROUTE object. Thus, the detour LSP terminates at R5.
R5もマージする必要があり、Fast_rerouteオブジェクトがあるため、メインのLSPを選択します。したがって、迂回路LSPはR5で終了します。
When an LSR receives a ResvTear for an LSP, the LSR must determine whether it has an alternate associated LSP. For instance, if the ResvTear was received for a protected LSP but an associated backup LSP has not received a ResvTear, then the LSR has an alternate associated LSP. If the LSR does not have an alternate associated LSP, then the MP MUST propagate the ResvTear toward the LSP's ingress, and, for each backup LSP merged into that LSP at this LSR, the ResvTear SHOULD also be propagated along the backup LSP.
LSRがLSPのRESVTEARを受信した場合、LSRは代替関連のLSPがあるかどうかを判断する必要があります。たとえば、保護されたLSPに対してResvTEARを受信したが、関連するバックアップLSPがRESVTEARを受信していない場合、LSRには代替関連のLSPがあります。LSRに代替関連のLSPがない場合、MPはLSPの侵入にresvtearを伝播する必要があり、このLSRでそのLSPにマージされた各バックアップLSPについて、resvTearもバックアップLSPに沿って伝播する必要があります。
The MP may receive PathTear messages for some of the merging LSPs. PathTear messages SHOULD NOT be propagated downstream until the MP has received PathTear messages for each of the merged LSPs. However, the fact that one or more of the merged LSPs has been torn down should be reflected in the downstream message, such as by changing the DETOUR object, if there is one.
MPは、マージするLSPの一部のPathtearメッセージを受信する場合があります。PATHTEARメッセージは、MPがマージされたLSPごとにPATHTEARメッセージを受信するまで、下流に伝播しないでください。ただし、マージされたLSPの1つまたは複数のLSPが取り壊されたという事実は、迂回オブジェクトがある場合、迂回オブジェクトを変更するなど、下流のメッセージに反映されるべきです。
When a downstream LSR detects a local link failure, for any protected LSPs routed over the failed link, Path and Resv state MUST NOT be cleared, and PathTear and ResvErr messages MUST NOT be sent immediately. If this is not the case, then the facility backup method will not work. Furthermore, a downstream LSR SHOULD reset the refresh timers for these LSPs as if they had just been refreshed. This is to allow time for the PLR to begin refreshing state via the bypass tunnel. State MUST be removed if it has not been refreshed before the refresh timer expires. This allows the facility backup method to work without requiring that it signal backup paths through the bypass tunnel before failure.
下流のLSRがローカルリンクの障害を検出した場合、故障したリンクを介してルーティングされた保護されたLSPの場合、PATHとRESV状態をクリアする必要はなく、PATHTEARおよびRESVERRメッセージをすぐに送信する必要はありません。そうでない場合、施設のバックアップ方法は機能しません。さらに、下流のLSRは、これらのLSPの更新タイマーをリフレッシュしたかのようにリセットする必要があります。これは、PLRがバイパストンネルを介して更新される状態を開始できるようにするためです。更新タイマーが期限切れになる前に更新されていない場合は、状態を削除する必要があります。これにより、故障前にバックアップパスをバックアップパスを通知することを必要とせずに、施設のバックアップ方法が動作することができます。
After a failure has occurred, the MP must still send Resv messages for the backup LSPs associated with the protected LSPs that have failed. If the backup LSP was sent through a bypass tunnel, then the PHOP object in its Path message will have the IP address of the associated PLR. This will ensure that Resv state is refreshed.
障害が発生した後、MPは、失敗した保護されたLSPに関連付けられたバックアップLSPのRESVメッセージを引き続き送信する必要があります。バックアップLSPがバイパストンネルを介して送信された場合、そのパスメッセージのPHOPオブジェクトには、関連するPLRのIPアドレスがあります。これにより、RESV状態が更新されます。
Once the local link has recovered, the MP may or may not accept Path messages for existing protected LSPs that had failed over to their backup.
ローカルリンクが回復すると、MPはバックアップに失敗した既存の保護されたLSPのパスメッセージを受け入れる場合と受け入れない場合があります。
The objects and methods defined in this document require behavior from all LSRs in the traffic-engineered network, even if an LSR is not along the path of a protected LSP.
このドキュメントで定義されているオブジェクトとメソッドは、LSRが保護されたLSPの経路に沿っていない場合でも、トラフィックエンジニアリングネットワーク内のすべてのLSRからの動作を必要とします。
First, if a DETOUR object is included in the backup LSP's path message for the sender template-specific method, the LSRs in the traffic-engineered network should support the DETOUR object.
まず、送信者テンプレート固有の方法のバックアップLSPのパスメッセージに迂回オブジェクトが含まれている場合、トラフィックエンジニアリングネットワークのLSRは迂回オブジェクトをサポートする必要があります。
Second, if the path-specific method is to be supported for the one-to-one backup method, it is necessary that the LSRs in the traffic-engineered network be capable of merging detours as specified in Section 8.1.
第二に、パス固有の方法が1対1のバックアップ方法でサポートされる場合、トラフィックエンジニアのネットワーク内のLSRは、セクション8.1で指定されているように迂回路を統合できる必要があります。
It is possible to avoid specific LSRs that do not support this behavior by assigning a link attribute to all the links of those LSPs and then requesting that backup paths exclude this link attribute.
これらのLSPのすべてのリンクにリンク属性を割り当て、バックアップパスがこのリンク属性を除外することを要求することにより、この動作をサポートしない特定のLSRを回避することができます。
If multiple Path Messages for different detours are received with the same SESSION, SENDER_TEMPLATE, outgoing interface, and next-hop LSR, then the LSR must function as a Detour Merge Point and merge the detour Path Messages. This merging should occur as specified in Section 7.1.2 and shown in Example 4.
同じセッション、Sender_Template、発信インターフェイス、およびNext-Hop LSRで異なる迂回の複数のパスメッセージが受信される場合、LSRは迂回マージポイントとして機能し、迂回路のパスメッセージをマージする必要があります。このマージは、セクション7.1.2で指定され、例4に示すように発生する必要があります。
In addition, it is necessary to update the DETOUR object to reflect the merging that has taken place. This is done using the following algorithm to format the outgoing DETOUR object for the final LSP:
さらに、発生したマージを反映するために迂回オブジェクトを更新する必要があります。これは、次のアルゴリズムを使用して行われ、最終的なLSPの発信迂回オブジェクトをフォーマットします。
- Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the DETOUR objects of all merged LSPs into a new object. Ordering is insignificant.
- すべての（plr_id、risem_node_id）ペアを、すべてのマージされたLSPのすべての迂回オブジェクトからのペアを新しいオブジェクトに組み合わせます。注文は取るに足らないものです。
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant.
このドキュメントでは、新しいセキュリティの問題は導入されていません。元のRSVPプロトコル[RSVP]に関連するセキュリティ上の考慮事項は引き続き関連しています。
Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other.
施設のバックアップ方法では、PLRとその選択されたMerge Point Trust RSVPメッセージが互いに受信される必要があることに注意してください。
IANA [RFC-IANA] has assigned the following RSVP Class Numbers for objects defined in this document.
IANA [RFC-AINA]は、このドキュメントで定義されているオブジェクトに、次のRSVPクラス番号を割り当てました。
IANA has assigned:
IANAが割り当てました：
63 DETOUR
63迂回
Class Types or C-Types:
クラスタイプまたはCタイプ：
7 IPv4 8 IPv6
7 IPv4 8 IPv6
Future C-Types will be assigned using the following guidelines:
将来のCタイプは、次のガイドラインを使用して割り当てられます。
C-Types 0 through 127 are assigned by Standards Action.
Cタイプ0〜127は、標準アクションによって割り当てられます。
C-Types 128 through 191 are assigned by Expert Review.
Cタイプ128から191は、専門家のレビューによって割り当てられます。
C-Types 192 through 255 are reserved for Vendor Private Use.
Cタイプ192〜255は、ベンダーの私的使用のために予約されています。
For C-Types in the range 192 through 255, the first four octets of the DETOUR object after the C-Type must be the Vendor's SMI Network Management Private Enterprise Code (see [ENT]) in network byte order.
192〜255の範囲のCタイプの場合、Cタイプの後の迂回路オブジェクトの最初の4オクテットは、ベンダーのSMIネットワーク管理プライベートエンタープライズコード（[ENT]を参照）でなければなりません。
IANA has assigned:
IANAが割り当てました：
205 FAST_REROUTE
205 fast_reroute
Class Types or C-Types:
クラスタイプまたはCタイプ：
1 FAST_REROUTE Type 1 7 RESERVED
1 fast_rerouteタイプ1 7予約
In the FAST_REROUTE object, C-Type 7 is reserved as it is still used by pre-standard implementations. Future C-Types will be assigned using the following guidelines:
fast_rerouteオブジェクトでは、標準以前の実装でまだ使用されているため、Cタイプ7は予約されています。将来のCタイプは、次のガイドラインを使用して割り当てられます。
C-Types 0 through 127 are assigned by Standards Action.
Cタイプ0〜127は、標準アクションによって割り当てられます。
C-Types 128 through 191 are assigned by Expert Review.
Cタイプ128から191は、専門家のレビューによって割り当てられます。
C-Types 192 through 255 are reserved for Vendor Private Use.
Cタイプ192〜255は、ベンダーの私的使用のために予約されています。
For C-Types in the range 192 through 255, the first four octets of the FAST_REROUTE object after the C-Type must be the Vendor's SMI Network Management Private Enterprise Code (see [ENT]) in network byte order.
192〜255の範囲のCタイプの場合、Cタイプの後のFAST_REROUTEオブジェクトの最初の4オクテットは、ベンダーのSMIネットワーク管理プライベートエンタープライズコード（[ENT]を参照）でなければなりません。
This document was written by George Swallow, Ping Pan, Alia Atlas, Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
この文書は、ジョージ・スワロー、ピン・パン、アリア・アトラス、ジャン・フィリップ・ヴァスザー、マルクス・ジョーク、デル・ハ・ガン、デイブ・クーパーによって書かれました。
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
Jean Philippe Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USA
Phone: +1 978 497 6238
EMail: jpv@cisco.com
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803 USA
Markus Jork Quarry Technologies 8ニューイングランドエグゼクティブパークバーリントン、マサチューセッツ州01803 USA
Phone: +1 781 359 5071
EMail: mjork@quarrytech.com
Der-Hwa Gan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
Der-Hwa Gan Juniper Networks 1194 N.Mathilda Ave Sunnyvale、CA 94089 USA
Phone: +1 408 745 2074
EMail: dhg@juniper.net
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 USA
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale、CA 94089 USA
Phone: +1 916 415 0437
EMail: dcooper@gblx.net
We would like to acknowledge input and helpful comments from Rob Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we thank those, who have been involved in interoperability testing and field trails, and provided invaluable ideas and suggestions. They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, Richard Southern, and Bijan Jabbari.
Rob Goguen、Tony Li、Yakov Rekhter、Curtis Villamizarからの入力と有益なコメントを認めたいと思います。特に、相互運用性のテストとフィールドトレイルに関与してきた人たちに感謝し、貴重なアイデアと提案を提供しました。彼らはロブ・ゴーゲン、キャロル・イトゥルラルデ、ブルック・ベイリー、サファー・ハサン、リチャード・サザン、ビジャン・ジャバリです。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RSVP-TE] 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.
[RSVP-TE] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSPトンネルのRSVPへの拡張"、RFC 3209、2001年12月。
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFCワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-Aiana] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[ENT] IANA PRIVATE ENTERPRISE NUMBERS, http://www.iana.org/assignments/enterprise-numbers
[ent] ianaプライベートエンタープライズ番号、http：//www.iana.org/assignments/enterprise-numbers
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
George Swallow Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USA
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 USA
Ping Pan Hammerhead Systems 640 Clyde Court Mountain View、CA 94043 USA
EMail: ppan@hammerheadsystems.com
Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA
Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica、MA 01862 USA
Phone: +1 978 964 2070
EMail: aatlas@avici.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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エディター機能の資金は現在、インターネット協会によって提供されています。