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
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).
著作権（C）インターネット協会（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.
この文書では、LSPトンネルのローカル修復のためのバックアップラベルスイッチパス（LSP）トンネルを確立するために、RSVP-TEの拡張を定義します。これらのメカニズムは、障害が発生した場合に、10ミリ秒にバックアップ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.
二つの方法がここで定義されています。一対一のバックアップ方式は、ローカル修復の各電位点における各保護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.
この文書では、LSPトンネルのローカル修復のためのバックアップラベルスイッチパス（LSP）トンネルを確立するために、RSVP [RSVP]を延びています。この拡張は、ユーザトラフィックが10ミリ秒でバックアップLSPトンネルにリダイレクトされる必要があるため、このようなボイスオーバー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）の電位点の挙動は、LSPを保護する方法と戦略のそれぞれを実装するための適切な戦略を決定する方法について説明し、セクション6に記載されています。セクション7は、LSR保護LSPと予備LSPの再結合、マージノードの挙動を記述する。最後に、第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、トラフィックエンジニアリングネットワーク内のLSRは、迂回オブジェクトをサポートすべきです。 DETOURオブジェクトを含むPathメッセージが拒否されていないようにするために必要です。
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を合理化。方法を行うことができる場合、応答は陽性であってもよいし、明確なエラーが代替バックアップ手段を求める要求者に通知することができます。この文書はまた、それによって機能の範囲を提供し、両方の方法をサポートするために単一の実装を可能にします。 LERとLSRのメソッドのいずれか、または両方を実装することを可能にするRSVPに説明した動作と拡張。
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つの方法が、原理的には単一のネットワークで使用することができますが、オペレータが1つまたは他のいずれかを展開し続けることが予想されます。この文書の目的は、方法またはその両方が正しく速い回復を達成するために、これらのLSRの間で信号を送ることができるサポートする一つの方法などをサポートするいくつかのLSRからなるネットワークの両方を実装するのLSRからなるネットワークように、RSVPシグナリングを標準化することです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC2119 [RFCワード]に記載されているように解釈されます。
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.
一対一のバックアップ：バックアップLSPは別途PLRで保護された各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は、それがそのホップに由来する一つまたは複数の関連付けられたバックアップトンネルを有する場合、所与のホップで保護されていると言われます。
Detour LSP: The LSP that is used to re-route traffic around a failure in one-to-one backup.
回り道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.
バックアップトンネル：多対1のバックアップでは、多くのLSPの1までのバックアップに使用されているLSP。
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single link of the protected LSP.
NHOPバイパストンネル：ネクストホップバイパストンネル。保護された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.
バックアップパス：LSP 1保護された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：迂回ポイントをマージします。一対一のバックアップの場合、これは複数の迂回路が収束LSRです。一つだけ回り道はそのLSRを超えて信号が送られます。
Reroutable LSP: Any LSP for which the head-end LSR requests local protection. See Section 5 for more detail.
Reroutable 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ディスジョイントは：パスは、パスがその所与のリンクまたはノードと同じ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つの異なる方法が記載されています。一対一のバックアップ方法では、PLRは、個別のバックアップLSPを計算し、PLRが保護することを各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.
一対一のバックアップ方法では、ラベルスイッチパスは、リンクまたはノードの障害点の下流のどこかに元の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]
保護されたLSP：[R1-> R2-> R3-> R4-> R5] R1のバックアップ：[R1-> R6-> R7-> R8-> R3] R2のバックアップ：[R2-> R7-> R8-> R4 】R3のバックアップ：[R3-> R8-> -R 9 - > R5] R4のバックアップ：[R4-> -R 9 - > R5]
Example 1. One-to-One Backup Technique
例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を作成することにより、ユーザトラフィックの保護を提供することができます。我々は迂回として部分一対一バックアップ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を保護するために、（1 N）と同数存在し得ます。実施例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は、トラフィックがリンクに沿って保護されたLSP上R1から受信切り替わり[R2-> R7]、R2は迂回を作成したときにラベルが受信使用。 R4は、R2の迂回するために設けられたラベルでトラフィックを受信した場合、R4は、リンク上にそのトラフィックを切り替える[R4-R5]、ラベルを使用します保護LSPのための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（S）のパスと交差しなければなりません。当然のことながら、これはいくつかの共通の下流のノードを通過するものにそのバイパストンネルを介してバックアップされる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]
保護されたLSP 1：[R1-> R2-> R3-> R4-> R5]保護LSP 2：[R8-> R2-> R3-> R4]保護LSP 3：R2-> R3-> R4-> R9 】バイパスLSPトンネル[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]から保護バイパストンネルを構築しました。二重線は、このトンネルを表します。同バイパストンネルはまた、R4、R5、またはR9のいずれかにR1、R2、又はR8のいずれかからLSPを保護するために使用することができるという点で、この技術は、スケーラビリティの向上を提供します。実施例2は、保護のために同一のバイパストンネルを使用している三つの異なる保護された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.
一対一の方法と同様に、完全にN個のノードを横断するLSPを保護するなど、多くの（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は、[R2-> R6]リンク上のトラフィックが保護されたLSP上R1から受信切り替わります。ラベルは、保護されたLSPを示すために、R4によって理解されるであろういずれかに切り替えられると、バイパストンネルのラベルは、その後、リダイレクトされたパケットのラベルスタックにプッシュします。最後から二番目のホップポッピングが使用される場合、実施例2の合流点は、R4は、パケットが追従すること保護LSPを示すラベルとリダイレクトされたパケットを受信します。最後から二番目のホップポッピングが使用されていない場合、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.
この仕様は、高速リルートシグナリングのためにRSVP-TEを拡張するために2つの追加のオブジェクト、FAST_REROUTE迂回を、定義します。これらの新しいオブジェクトがそれらを認識しないのLSRとの下位互換性があります（[RSVP]でセクション3.10を参照してください）。両方のオブジェクトはRSVPのPathメッセージで行うことができます。
The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to support bandwidth and node protection features.
SESSION_ATTRIBUTEと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によってPATHメッセージに挿入されなければならないと下流のLSRによって変更してはなりません。 FAST_REROUTEオブジェクトの形式は次のとおりです。
Class-Num = 205 C-Type = 1
クラスのNum = 205 C-タイプ= 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のワン・ツー・ワンのバックアップ
Requests protection via the one-to-one backup method.
一対一のバックアップ方法を経由して保護を要求します。
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浮動小数点整数、。
Exclude-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
含める-いずれかを
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ビットのベクター。空集合（すべてのビットがゼロに設定）を自動的に通過します。
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ビットのベクトル。空集合（すべてのビットがゼロに設定）を自動的に通過します。
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.
それを無視し、それが前方にそのまま渡すようにオブジェクトを理解していないクラスのNum（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-Type値とフォーマットを以下に指定されています。これは、従来の実装で使用されています。フィールドの意味は、C-1型について説明したのと同様です。
Class-Num = 205 C-Type = 7
クラスのNum = 205 C-タイプ= 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.
[RSVP] 3.10で指定されるように、未知のC-タイプは、治療されるべきです。
The DETOUR object is used in the one-to-one backup method to identify detour LSPs.
迂回オブジェクトは、迂回LSPを識別するために、一対一のバックアップ方法において使用されます。
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.
迂回の開始点であるPLRを特定するIPv4アドレス。 PLR上の任意のローカルアドレスを使用することができます。
Avoid_Node_ID (1 - n)
Avoid_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.
PLRは避けるようにしようとしている即時の下流ノードを特定するIPv4アドレス。下流ノードの任意のローカルアドレスを使用することができます。このフィールドは必須であり、以下に説明マージルールのMPによって使用されます。
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)
Avoid_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.
PLRが回避しようとしている直下流ノードを識別するIPv6の128ビットのユニキャストホストアドレス。下流のノード上の任意のローカルアドレスを使用することができます。このフィールドは必須であり、以下に説明マージルールの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、Avoid_Node_ID）エントリの複数のペアが存在することができます。迂回マージを希望する場合は、各マージ操作の後、回り道マージポイントは、後続のPathメッセージ内のすべてのマージされた迂回路を結合する必要があります。
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".
クラス民の上位ビットはゼロです。 DETOURオブジェクトをサポートしていないのLSRはDETOURオブジェクトを含む任意のPathメッセージを拒否してPLRを通知するのPathErrを送らなければなりません。クラス民形の「0bbbbbbbは」未知のオブジェクトに対して[RSVP]で指定されたPathErrこれは、生成されるべきです。
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
[RSVP] 3.10で指定されるように、未知のC-タイプは、治療されるべきです。
To request bandwidth and node protection explicitly, two new flags are defined in the SESSION_ATTRIBUTE object.
明示的な帯域幅およびノード保護を要求するには、二つの新しいフラグがSESSION_ATTRIBUTEオブジェクトで定義されています。
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has the following flags defined [RSVP-TE]:
C-1型及び7の両方のために、セッション属性オブジェクトは現在[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.
このフラグは、トンネル入口ノードは、それを切断することなく、このトンネルを再ルーティングすることを選択することができることを示しています。 Resvメッセージで応答する場合、トンネル出口ノードは、SEスタイルを使用すべきです。高速再ルーティングを要求するとき、ヘッドエンドLSRは、このフラグを設定すべきです。これは、1対1のバックアップ方法の経路特異的方法のために必要ではありません。
The following new flags are defined:
次の新しいフラグは定義されています。
Bandwidth protection desired: 0x08
帯域幅保護が望ま：0×08
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の経路に沿ってPLRsに示します。何FAST_REROUTEオブジェクトがPATHメッセージに含まれていない場合、保証される帯域幅は、保護されたLSPのものです。 FAST_REROUTEオブジェクトは、PATHメッセージ内にある場合、そこに指定された帯域幅が保証されるべきです。
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の次のノードを迂回する予備パスが所望される保護されたLSPの経路に沿ってPLRsに示します。
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サブオブジェクトに二つの新しいフラグを定義します。
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:
二つの新しいフラグが定義されています。
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.
保護されたLSPがないFAST_REROUTEオブジェクトが含まれていなかった場合、FAST_REROUTEオブジェクトまたは保護LSPの帯域幅で指定される所望の帯域幅を提供することが保証されている予備パスを有する場合PLRは、このビットをセットします。 PLRは、所望の帯域幅が保証されるたびにこれを設定してもよいです。所望の帯域幅が保証され、「帯域幅保護を希望」フラグがSESSION_ATTRIBUTEオブジェクトに設定されたとき、PLRは、このフラグを設定しなければなりません。要求された帯域幅が保証されていない場合は、PLRは、このフラグを設定してはいけません。
Node protection: 0x08
ノード保護：0×08
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.
保護されたLSPが保護LSPに沿って次のLSRの障害に対する保護を提供する予備パスを有する場合PLRは、このビットをセットします。ノード保護が保護LSPのバックアップパスによって提供されるたびにPLRはこれを設定してもよいです。ノード保護が提供され、「ノード保護所望の」フラグは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オブジェクトの「ローカル保護所望の」フラグを設定するか、PATHメッセージ、またはその両方でFAST_REROUTEオブジェクトを含める必要があります。 SESSION_ATTRIBUTEオブジェクト内の「ローカル保護たい」フラグは常にセットされるべきである（SHOULD）。ヘッドエンド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オブジェクトを含むべきです。 PLRsは、バックアップパスを決定するために属性フィルタ、帯域幅、ホップ制限、および優先順位を使用します。
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は一対一のバックアップ方法は、保護されたLSPのために使用することを望む場合には、ヘッドエンドLSRはFAST_REROUTEオブジェクトを含み、「一対一バックアップ所望の」フラグを設定しなければなりません。ヘッドエンドLSRが保護LSPが施設バックアップ方法によって保護されることを望む場合には、ヘッドエンドLSRはFAST_REROUTEオブジェクトを含み、「施設バックアップ所望の」フラグを設定しなければなりません。 FAST_REROUTEオブジェクトの欠如、またはクリアこれらのフラグの両方を有するが、嗜好性の欠如としてPLRsによって扱われるべきです。両方のフラグが設定されている場合は、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.
セクション4.4で定義された追加のフラグをサポートしなければならない保護されたLSPのヘッドエンドLSRはRRO IPv4とIPv6のサブオブジェクトで設定またはクリアされています。保護された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オブジェクト、「ラベルが所望の記録」「ノード保護が所望の」「は、所望のローカル保護」、およびSESSION_ATTRIBUTEオブジェクトにフラグを「所望の帯域幅保護」、および「利用可能なローカル保護」、「ローカル保護をサポートすべきです使用中」、 『RRO IPv4とIPv6のサブオブジェクトにおける帯域幅保護』、および 『ノード保護』フラグ。 PLRはDETOURオブジェクトをサポートするかもしれません。
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は、「ローカル保護が所望の」場合、ローカルの保護を求めているためにLSPを考慮しなければならないフラグがSESSION_ATTRIBUTEオブジェクトに設定されている、および/またはFAST_REROUTEオブジェクトが含まれています。 FAST_REROUTEオブジェクトが含まれている場合、PLRは「一対一たい」場合は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は「地元の保護可能な」フラグを設定しなければなりません。確立さ一対一バックアップLSP又はバイパストンネルが存在しない場合は一対一のLSPとバイパストンネルが「DOWN」状態にある場合、又は、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.
- それは積極的にバックアップパスへの代わりに、保護されたLSPに沿ってトラフィックをリダイレクトされない限り、PLRは「地元の保護、使用中」フラグをクリアしなければなりません。
- 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トンネルは[RSVP-TE]をSESSIONとSENDER_TEMPLATEオブジェクトの組み合わせによって識別されます。次のように関連するフィールドがあります。
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）の識別子。通常、それはすべてゼロに設定されています。入・出力ペアにSESSIONの範囲を狭めることを望むのIngressノードは、グローバルに一意の識別子として、ここで自分の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.
これらの最初の三つは、セッションオブジェクトにあり、トンネルのための基本的な識別情報です。ヘッドエンドLSRのIPアドレスに「拡張トンネルID」を設定すると、SESSIONの範囲は、その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.
最後の二つはSENDER_TEMPLATEです。同じセッション内の複数のLSPは、保護されていてもよいし、異なる経路を取ることができます。トンネルはメイクの前にブレーク使用して再ルーティングされたときに、これは一般的です。バックアップパスは明らかに正しいマージ状態の治療を可能にするために、その保護されたLSPで識別されなければなりません。したがって、バックアップパスは、関連する保護LSPからのLSP IDを継承しなければなりません。したがって、バックアップパスと保護LSPの間で変化することができSESSIONと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で使用されるものと同じSESSIONとSENDER_TEMPLATEオブジェクトを使用します。 Pathメッセージで迂回物体の存在は、バックアップパスを意味します。 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.
Pathメッセージに特異的なアプローチでは、LSRは同じSESSIONとSENDER_TEMPLATEオブジェクトを受信し、それは、同じネクストホップオブジェクトを有するPathメッセージをマージします。この行動がなければ、バックアップパスを持つ複数のRESVメッセージを関連付けることは不可能であろう。しかし、このマージ動作が異なるエロスとLSPをマージを犠牲にしてネットワーク内の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を回避する必要があります。送信者テンプレート固有モードでは、この同じ制限を迂回し、その帯域幅は一度だけ確保されているその保護された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.
- リンク属性フィルタが適用されます。それはそうでなければ、PATHメッセージ内、又は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.
- それはそうでなければ、PATHメッセージ内、又はSESSION_ATTRIBUTEオブジェクトに含まれている場合に使用される帯域幅は、FAST_REROUTEオブジェクトに見出されます。ローカルポリシーは、帯域幅を予約する修正することができます。
- The hop-limit, if a FAST_REROUTE object was included in the PATH message.
- ホップリミット、FAST_REROUTEオブジェクトがPATHメッセージに含まれていた場合。
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.
- 一対一の保護はパス固有のメソッドを使用して設定されている場合、迂回は同じ方向に保護されたLSPの上流のリンクをトラバースしないしなければなりません。これは、保護されたLSPに迂回の早期合併の可能性を防ぐことができます。一対一の保護は、送信者テンプレート固有の方法を使用して設定されている場合、迂回は同じ方向に保護されたLSPの上流のリンクを通過しないでください。これは、保護されたLSPと帯域幅は、障害発生時に二回使用される故障の上流にそのバックアップの間の帯域幅を共有しないように。
- 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は最後から二番目のホップである場合には、ノード保護ができないことに注意してください、とだけ下流のリンクを回避することができます。バックアップパスは回避されている下流ノードおよび/またはリンクから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は一対一のバックアップとローカル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のPATHメッセージを作成するには、保護されたLSPのPATHメッセージ時に実行される変換について説明します。
- 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は、保護のために用いたものと同じではないPLRに属するアドレスにSENDER_TEMPLATEの「はIPv4（またはIPv6）トンネルの送信元アドレス」を変更する必要がありますLSP。また、迂回オブジェクトは、PATHメッセージに追加されてもよいです。
- If the path-specific method is to be used, then the PLR MUST add a DETOUR object to the PATH message.
- 経路別の方法が使用される場合、PLRは、PATHメッセージに迂回オブジェクトを追加しなければなりません。
- 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オブジェクトの包含いずれか、任意の除外、及び包含すべてのフィールドが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のPathメッセージがFAST_REROUTEオブジェクトが含まれている場合、このオブジェクトは、迂回LSPのPATHメッセージから削除する必要があります。
- 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は、マージポイントに属する第1のアドレスの前にすべてのサブオブジェクトを削除する必要があります。次いで、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.
- 保護されたLSPのPATHメッセージに含まれている場合SENDER_TSPECオブジェクトは、受信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.
回り道LSPは、通常のLSPのように動作します。迂回経路が正常に計算され、迂回LSPが確立されると、PLR（1）FAST_REROUTEの内容が変更されていない限り、再度迂回ルートを計算または保護LSP（2）下流インタフェースおよび/またはネクストホップルータである必要はありません変更されました。 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とメイクの前にブレークを行うことが可能です。これは、（保護されたLSPのSENDER_TEMPLATEで使用されていなかった）PLRに属する2つの異なるIPアドレスを使用して行われます。現在の迂回LSPがそのSENDER_TEMPLATEの最初のIPアドレスを使用する場合、新しい迂回LSPは、そのSENDER_TEMPLATEにおける2番目のIPアドレスを使用することによって合図されなければなりません。新しい迂回LSPが作成されると、現在の迂回LSPが切断することができます。これらのIPアドレスの使用を交互にすることにより、現在、新たな迂回LSPは、下流のLSRでこのように、異なる状態を異なるSENDER_TEMPLATESを持っているでしょう。
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.
彼らは共通ネクストを共有している場合、新規および現在の迂回LSPのためのPATHメッセージをマージすることができるよう代わりに迂回対象にPLR IPアドレスを変更し、このメイク・ビフォア・ブレイクメカニズムは、パス固有の方法では実現不可能ですホップ。
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メッセージを受信した場合同様に、それは、関連する迂回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の両方を削除しなければなりません。 PathTearメッセージは、両方の保護と回り道のLSPに伝播しなければなりません。エラー状態の間、LSRには失敗し、パス上の問題を修正するた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]
保護されたLSP：[R1-> R2-> R3-> R4-> R5]迂回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.
リンク[R2-> R3]が失敗した場合、実施例3では、R2は、次のことを行うだろう。すべてのトラフィックは、に沿って（ラベルL34と[R3-> R4（迂回LSPに沿って）ラベルL46との代わりに、リンクの[R2-> R6]ラベルL32と[R1-> R2]がリンク上で送信されるリンク上で受信しました保護されたLSP）。合流点は、R4は、パケットがラベルL35と[R4-> R5]リンク上で送信され、それらが保護LSPとマージされるべきであるとされるべきであるラベルL44と[R7-> R4]リンク上で受信されたことを認識するであろう。
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オブジェクトにフラグを「ラベル記録が要求されました」。そのINBOUNDラベルを記録するために、ラベルはLSRにグローバルであるかどうかのフラグを経由して注意することは、全てのLSR（[RSVP-TE]に指定されている）これが原因となります。保護された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のために）Pathメッセージを送信しなければなりません。このためのシグナリング手順は、以下のセクション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.
- SESSIONは変更されません。
- 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.
、「帯域幅保護が望ま」「ローカル保護が望ま」、および「ノード保護の希望」のフラグがクリアされるべきである： - SESSION_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メッセージを複製し、PLRと保護LSPのRSVP_HOPオブジェクトによって示された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]に記載されています。このセクションでは、バイパストンネルを介して送信されるPathメッセージのための追加ERO更新手順を説明します。通常のERO処理ルールが守られた場合は、マージポイントは、最初のサブオブジェクトを調べて、おそらく（サブオブジェクト悪い初期）、それを拒絶するでしょう。未修飾のEROが（NNHOPバイパストンネルの場合）バイパスノード又は（NHOPバックアップトンネルの場合）、現在ダウンしているインターフェイスのIPアドレスが含まれている可能性があるためです。この理由のために、PLRが、バイパストンネルを介してPathメッセージを送信する前に、次の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に属する第1サブオブジェクトと共に、除去されます。バックアップトンネルの宛先を識別するサブオブジェクトは、追加されます。
More specifically, the PLR MUST:
具体的には、PLRの必要があります。
- remove all the sub-objects proceeding the first address belonging to the MP, and
- MPに属する第1のアドレスを進め、すべてのサブオブジェクトを削除し、そして
- replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.)
- MPのIPアドレスを使用して、この最初のMPアドレスを交換してください。 （これは単に削除されたのと同じアドレスにすることができることに注意してください。）
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.
高速再ルーティングの間に、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.
さらに、ヘッドエンドは、LSPがIGPを介して報告された障害に注目することによって、より最適なパスに移動されなければならないことを検出してもよいです。エリア間TE 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をreoptimizingする責任があります。 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の各々： - ローカル・リバーティブモード。正常に復元されたリソースに沿って再合図すべての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属性に基づいて、ヘッドエンドLSRによって行われる一方、ローカルリバーティブモードでは、任意TE LSPは、任意の区別なく、スイッチバックされます。ヘッドエンドは、障害の学習時にリソースとTE LSP制約のより完全なビューを有するように、それは、異なる、より最適な経路に沿って保護LSPトンネルを再最適化することができます。これは、に戻ってきた古いLSPがもはや最適ではないかもしれないということを意味します。 TE LSPの経路計算は、いくつかの経路計算要素に行われる可能性があるエリア間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.
しかし、（パスはオフライン最適化ツールを使用して決定される場合に望ましいかもしれないように保護されたLSPがダウン固定されている場合、例えば、）ヘッドエンドは、TE 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は、タイムリーな応答を行うために、エラーメッセージ、および/またはIGPの適応症をRSVPに反応すべきです。
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をRESIGNALする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.
それが保護されたLSPとその保護LSPにマージされたバックアップLSPのための1つ以上のメッセージのパスメッセージを受信した場合LSRは合流点です。一対一のバックアップ方法では、LSRは、それが故障する前にマージノードであることを認識しています。施設バックアップ方法では、LSRは、障害が発生し、それがバックアップLSPのPathメッセージを受信するまで、それは合流点であることを知らないかもしれません。したがって、保護された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のPathメッセージを受信すると、共通ヘッダにSend_TTLは、Pathメッセージが転送された内の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は一対一のバックアップ方法を介してローカル保護を提供している場合は、最初の場合には、迂回が通知され、適切に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.
第二のケースでは、合流点は、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は、保護されたLSPのために、おそらく、1つ以上のバックアップLSPのために複数のPathメッセージを受信してあります。これらのPathメッセージはそれぞれ異なるSENDER_TEMPLATEを持つことになります。それはSESSION_ATTRIBUTEオブジェクト、またはその両方に設定されている「ローカル保護所望の」フラグFAST_REROUTEオブジェクトを含む又は有することになるので、保護LSPを認識することができます。
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が同じである場合には、Pathメッセージは、マージの対象となります。同様にRESVメッセージ、そのERO出口へのLSRからマージすることができる同じであるのみPathメッセージをマージする[RSVP-TE]で指定します。マージが発生した場合はPathメッセージのいずれかが保護されたLSPのためだった合併し、その後、送信する最後のPathメッセージは、保護されたLSPのものでなければなりません。これは、そのLSRで保護されたLSPにバックアップLSPをマージします。最終Pathメッセージが同定されたならば、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のために、その後DETOURオブジェクトであれば任意の場合、セクション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）と同じSESSIONとSENDER_TEMPLATEオブジェクトと異なるインターフェースから複数のPathメッセージを受信することができます。この場合、パスの状態のマージが必要になります。次のようにマージルールは次のとおりです。
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].
すべてのPathメッセージが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はパスの状態や着信インターフェイスを記録しなければなりません。 Pathメッセージは、発信インターフェイスおよびネクストホップ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は、下流転送するPathメッセージを作成するには、次の手順を実行します。
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.
Pathメッセージの1つ以上が保護LSPのためのものである場合は1を、（保護されたLSPは、一本のノードから、又はFAST_REROUTEオブジェクトに、または迂回オブジェクトなしで発信されている）、これらの一方が選択されたPathメッセージにならなければなりません。複数があるかもしれません。その場合には、前方にどちらがローカル決定です。終了する。
2. From the remaining set of Detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid.
迂回Pathメッセージの残りのセット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.
転送する1いくつかは、まだ残っている場合3.、地元の決定です。何も残っていない場合は、MPはマージ迂回パスを回避したいすべてのノードを回避し、新たなルートを見つけることを試みるかもしれません。そのEROとPathメッセージを転送します。
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.
最終Pathメッセージが同定されたならば、MPは、定期的に下流それをリフレッシュするために開始する必要があります。他のLSPは、このノードでマージと考えられています。発信リンク上の帯域幅の予約の場合は、任意のマージは、帯域幅が予約される前に発生していると考えるべきです。このように、固定フィルタスタイルが指定されていても、複数の迂回および/または（原因発信インターフェイスとネクストホップLSRを共有にマージされる）は、それらの保護されたLSPは、発信インターフェイス上の最終的なPathメッセージの唯一の帯域幅を予約します。
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.
何のマージされたPathメッセージが構築できない場合は、MPは、最後に受信迂回Pathメッセージに反応しての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]
保護されたLSP：[R1-> R2-> R3-> R4-> R5-> R6] R2の迂回：R2-> R7-> R8-> -R 9 - > R4-> R5-> R6】R3の迂回：[R3 - > R8-> -R 9 - > 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のための迂回から同じSESSIONとSENDER_TEMPLATEを有するPathメッセージを受信します。迂回R3が短くERO経路長を有するので、R8で合流時（すなわち、EROが[-R 9 - > R5-> R6]である、及び経路長は3）、R8は、最終的なLSPとして選択するだけ伝播し、その下流Pathメッセージ。 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を持っているかどうかを決定しなければなりません。たResvTearが保護LSPのために受信されたが、関連するバックアップLSPがたResvTearを受信していない場合、例えば、その後、LSRは、代替関連LSPを有しています。 LSRが代替関連するLSPを持っていない場合は、各バックアップLSPがこのLSRでそのLSPにマージするために、そしてMPは、LSPの入口に向かったResvTearに伝播して、しなければならない、たResvTearもバックアップLSPに沿って伝播されるべきである（SHOULD）。
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メッセージを受け取ることができます。 MPがマージされたLSPのそれぞれについて、PathTearメッセージを受信するまでPathTearメッセージを下流に伝播されるべきではありません。一方が存在する場合は、マージされたLSPの1つ以上が取り壊されているという事実は、そのような迂回オブジェクトを変更することなどによって、下流メッセージに反映されるべきです。
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のために、パスとの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.
DETOURオブジェクトは、送信者のテンプレート特有の方法のバックアップLSPのパスメッセージに含まれている場合、最初に、トラフィックエンジニアリングネットワーク内のLSRはDETOURオブジェクトをサポートする必要があります。
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.
パス具体的な方法は、一対一のバックアップ方法をサポートする場合には、第2、セクション8.1で指定されたトラフィックエンジニアリングネットワーク内のLSRが、迂回路をマージすることが可能であることが必要です。
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.
異なる迂回するための複数のPathメッセージは同じSESSION、SENDER_TEMPLATE、出力インターフェース、およびネクストホップ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.
- 新しいオブジェクトにすべてのマージされたLSPのすべての迂回オブジェクトからすべての（PLR_ID、Avoid_Node_ID）のペアを結合します。注文は軽微であります。
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、その選択された合流点の信頼RSVPメッセージがお互いから受信している必要があることに注意してください。
IANA [RFC-IANA] has assigned the following RSVP Class Numbers for objects defined in this document.
IANA [RFC-IANAは、この文書で定義されたオブジェクトは、次のRSVPクラス番号を割り当てました。
IANA has assigned:
IANAが割り当てられています：
63 DETOUR
63 DETOUR
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.
191 128〜C-タイプは、専門家レビューによって割り当てられます。
C-Types 192 through 255 are reserved for Vendor Private Use.
C-タイプ255 192は、ベンダーのプライベート利用のために予約されています。
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 RESERVED
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.
191 128〜C-タイプは、専門家レビューによって割り当てられます。
C-Types 192 through 255 are reserved for Vendor Private Use.
C-タイプ255 192は、ベンダーのプライベート利用のために予約されています。
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.
この文書は、ジョージくん、Pingのパン、アリアアトラス、ジャン・フィリップVasseur、マルクスJorkの、デア・ファガン、そしてデイブ・クーパーによって書かれました。
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
ジャン・フィリップVasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA
Phone: +1 978 497 6238 EMail: jpv@cisco.com
電話：+1 978 497 6238 Eメール：jpv@cisco.com
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803 USA
マルクスJorkの採石・テクノロジーズ8ニューイングランド・エグゼクティブ・パークバーリントン、MA 01803 USA
Phone: +1 781 359 5071 EMail: mjork@quarrytech.com
電話：+1 781 359 5071 Eメール：mjork@quarrytech.com
Der-Hwa Gan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
後期空気ガンジュニパーネットワークス1194 Nkmthildaアベニューサニーベール、94089それ
Phone: +1 408 745 2074 EMail: dhg@juniper.net
電話：+1 408 745 2074 Eメール：dhg@juniper.net
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 USA
デイブ・クーパーグローバル・クロッシング960ハムリン法廷サニーベール、CA 94089 USA
Phone: +1 916 415 0437 EMail: dcooper@gblx.net
電話：+1 916 415 0437 Eメール：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.
我々はロブGoguen、トニー・リー、ヤコフ・レックターとカーティスVillamizarからの入力や有益なコメントを承認したいと思います。特に、我々は、相互運用性テストとフィールドトレイルに関与し、貴重なアイデアや提案を提供してきた人たちに感謝します。彼らはロブGoguen、キャロルIturralde、ブルック・ベイリー、Safaaハサン、リチャード・南部、およびビジャンJabbariです。
[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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：Extensionsが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-WORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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-IANA] 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
ジョージツバメシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA
Phone: +1 978 244 8143 EMail: swallow@cisco.com
電話：+1 978 244 8143 Eメール：swallow@cisco.com
Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 USA
Pingのパンハンマーシステム640クライド法廷マウンテンビュー、CA 94043 USA
EMail: ppan@hammerheadsystems.com
メールアドレス：ppan@hammerheadsystems.com
Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA
アリアアトラスAviciシステム101ビレリカアベニューN.ビレリカ、MA 01862 USA
Phone: +1 978 964 2070 EMail: aatlas@avici.com
電話：+1 978 964 2070 Eメール：aatlas@avici.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。