RFC4090 日本語訳
4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. P. Pan, Ed.,G. Swallow, Ed., A. Atlas, Ed.. May 2005. (Format: TXT=83965 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
エド、ワーキンググループP.なべをネットワークでつないでください。コメントのために以下を要求してください。 4090年のハンマーの頭システムカテゴリ: 規格はシステム2005年5月にエドG.ツバメ、エドシスコシステムズA.Atlas、Aviciを追跡します。
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
2つの方法がここで定義されます。 1〜1つのバックアップ方法がそれぞれの保護されたLSPのためにそれぞれの潜在的ポイントの局部的修繕で回り道LSPsを作成します。 施設バックアップ方法は起こりうる失敗ポイントを保護するために迂回トンネルを作成します。 MPLSラベルの積み重ねを利用することによって、この迂回トンネルは同様のバックアップ規制を持っているLSPsの1セットを保護できます。 ネットワーク失敗の間、リンクとノードを保護するのに両方の方法を使用できます。 RSVPへの説明された振舞いと拡大で、ノードは、方法か両方のどちらかを実行して、複雑なネットワークで共同利用します。
Pan, et al. Standards Track [Page 1] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[1ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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
1. 序論…3 1.1. バックグラウンド…4 2. 用語…4 3. 局部的修繕のテクニック…6 3.1. 1〜1つのバックアップ…6 3.2. 施設バックアップ…7 4. RSVP拡張子…8 4.1. 速い_は物を別ルートで送ります…8 4.2. 物を迂回してください…11 4.2.1. IPv4アドレスのために物を迂回してください…11 4.2.2. IPv6アドレスのために物を迂回してください…12 4.3. セッション_属性は弛みます…13 4.4. RRO IPv4/IPv6サブオブジェクト識別子…14 5. ギヤエンドの振舞い…15 6. 局部的修繕(PLR)の振舞いのポイント…16 6.1. バックアップ道に合図します…17 6.1.1. 経路識別のバックアップをとってください: 送付者テンプレート詳細…19 6.1.2. 経路識別のバックアップをとってください: 経路特有…19 6.2. バックアップ経路計算のための手順…20 6.3. 1〜1のためのシグナリングバックアップ保護…21 6.3.1. 以前、回り道LSPsと共に開閉してください…22 6.3.2. メッセージハンドリング…23 6.3.3. ローカルは回り道LSPに交通のコースを変更します…23 6.4. 施設保護のために、合図します…24 6.4.1. 川下のラベルを発見します…24 6.4.2. 地方である前にPLRのための手順は修理されます…24 6.4.3. 地方の間のPLRのための手順は修理されます…25 6.4.4. 処理バックアップトンネルのERO…26 6.5. 局部的修繕の間のPLR手順…26 6.5.1. 局部的修繕の通知…26 6.5.2. Revertiveの振舞い…27 7. ノードの振舞いを合併してください…28 7.1. 失敗の前の取り扱いバックアップ経路メッセージ…28 7.1.1. 送付者のテンプレート特有の方法を使用することでバックアップ道を合併します…29 7.1.2. 合併は経路特有の方法を使用することで遠回りします…29 7.1.3. 合併している回り道のためのメッセージハンドリング…31 7.2. 取り扱い失敗…31 8. すべてのLSRsの動き…32 8.1. 合併は経路特有の方法で遠回りします…32 9. セキュリティ問題…33 10. IANA問題…33 11. 貢献者…35 12. 承認…36 13. 標準の参照…36
Pan, et al. Standards Track [Page 2] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[2ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
1. Introduction
1. 序論
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トンネルを計算して、合図して、可能であるとしての失敗ポイントの近くように交通を向け直すことによって、このタイミング要件を満たすことができます。 このように、リダイレクションのための時間は経路計算がなくてシグナリング遅れを全く含んでいません、ラベルで切り換えられたルータ(LSRs)の間の失敗通知を伝播するために遅れを含んでいて。 修理の速度はここで説明された方法と拡大の第一の利点です。 局所制御不能に対応してバックアップ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です。 ここで説明された修理方法は明らかに発送されたLSPsだけに適切です。 ダイナミックにユニキャストIGPルーティングで使用されるLSPsなどの彼らのルートを変えるLSPsへのこれらの方法の利用はこのドキュメントの範囲を超えています。
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はバックアップLSPsを作成するための2つの基本的方法を説明します。 セクション4は、地方の保護を支持するためにRSVPプロトコル拡張子について説明します。 セクション5はLSPのために地方の保護を要求しようとするLSRの動きを提示します。 セクション6で局部的修繕(PLR)の潜在的ポイントの動きを与えます。(それは、どのようにLSPを保護するための適切な戦略を決定するか、そして、どのようにそれぞれの戦略を実行するかを説明します)。 セクション7はマージノードの動き、保護されたLSPとそのバックアップLSPが再び加わるLSRについて説明します。 最終的に、セクション8はネットワークにおける、他のノードの必要な動きについて議論します。
The methods discussed in this document depend upon three assumptions:
本書では議論した方法は3つの仮定によります:
o An LSR that is on the path of a protected LSP should always
assume that it is a merge point. This is necessary because
the facility backup method does not signal backups through a
bypass tunnel before failure.
o 保護されたLSPの経路にあるLSRは、いつもそれがマージポイントであると仮定するはずです。 施設バックアップ方法が失敗の前に迂回トンネルを通ってバックアップを示さないので、これが必要です。
o If the one-to-one backup method is used and a DETOUR object
is included, the LSRs in the traffic-engineered network
should support the DETOUR object. This is necessary so that
the Path message containing the DETOUR object is not
rejected.
o 1〜1つのバックアップ方法が使用されていて、DETOUR物が含まれているなら、交通で設計されたネットワークにおけるLSRsはDETOUR物を支えるはずです。 これが必要であるので、DETOUR物を含むPathメッセージは拒絶されません。
Pan, et al. Standards Track [Page 3] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[3ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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 DETOUR物を理解するのが、経路特有の方法を支持するのに必要です。(方法は、交通で設計されたネットワークにおけるLSRsが回り道を合併できるのを必要とします)。
1.1. Background
1.1. バックグラウンド
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を配備しました。 これらの方法はここに呼ばれます。バックアップと施設がバックアップをとる一対一。 両方の方法で共同利用できるただ一つの実現を起こすのを試みる際に両方の方法を支持しようとする業者が互換性の問題を経験しました。 方法の間には、技術的な見返りがあります。 共同体にはいる扶養家族がただ一つのアプローチに位相的に集まらないで、これらの見返りはそうです。
This document rationalizes the RSVP signaling for both methods so that any implementation can recognize all fast reroute requests and clearly respond. The response may be positive if the method can be performed, or it may be a clear error to inform the requester to seek alternate backup means. This document also allows a single implementation to support both methods, thereby providing a range of capabilities. The described behavior and extensions to RSVP allow LERs and LSRs to implement either method or both.
どんな実現もすべてが速く要求を別ルートで送って、明確に応じると認めることができて、このドキュメントは両方の方法のためにRSVPシグナリングを合理化します。 方法を実行できるなら、応答は積極的であるかもしれませんか、交互のバックアップ手段を求めるためにリクエスタを知らせるのが、明確な誤りであるかもしれません。 また、ただ一つの実現はこのドキュメントで両方の方法を支持して、その結果、さまざまな能力を提供できます。 RSVPへの説明された振舞いと拡大で、LERsとLSRsは方法か両方のどちらかを実行できます。
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つの方法を支持するいくつかのLSRsで構成された方法かネットワークと両方を支持する他のものの両方を実行するLSRsで構成されたネットワークが、それらのLSRsの中に速い回復を達成するのを適切に示すことができるようにRSVPシグナリングを標準化することです。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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トンネルを修理していました。
Pan, et al. Standards Track [Page 4] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[4ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
PLR: Point of Local Repair. The head-end LSR of a backup tunnel
or a detour LSP.
PLR: 局部的修繕のポイント。 バックアップトンネルか回り道LSPのギヤエンドLSR。
One-to-One Backup: A local repair method in which a backup LSP is
separately created for each protected LSP at a PLR.
1〜1つのバックアップ: バックアップ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.
施設バックアップ: 迂回トンネルが1つを保護するのに使用される局部的修繕方法か以上がそのオーダーでPLR、保護されるリソース、およびMerge Pointを横断するLSPsを保護しました。
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: それには1つがあるか、またはおまけに、由来する複数の関連バックアップトンネルが跳ぶなら、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.
トンネルを迂回させてください: 一般的な施設を通り過ぎるLSPsの1セットを保護するのに使用されるLSP。
Backup Tunnel: The LSP that is used to backup up one of the many
LSPs in many-to-one backup.
トンネルのバックアップをとってください: 1つへの多くにおけるLSPsがバックアップをとる多くのうちの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.
経路のバックアップをとってください: 1つを支援するのに責任があるLSPはLSPを保護しました。 バックアップ道は回り道LSPかバックアップトンネルのどちらかについて言及します。
MP: Merge Point. The LSR where one or more backup tunnels rejoin
the path of the protected LSP downstream of the potential
failure. The same LSR may be both an MP and a PLR
simultaneously.
MP: ポイントを合併してください。 1つ以上のバックアップがトンネルを堀るLSRは起こりうる失敗の保護されたLSP川下の経路に再び加わります。 同時に、同じLSRはMPとPLRの両方であるかもしれません。
DMP: Detour Merge Point. In the case of one-to-one backup, this
is an LSR where multiple detours converge. Only one detour
is signaled beyond that LSR.
DMP: 回り道マージポイント。 1〜1つのバックアップの場合では、これは複数の回り道が一点に集まるLSRです。 1つの回り道だけがその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: 最短パス規制ベースの1番目。
Pan, et al. Standards Track [Page 5] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[5ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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が与えられたリンクかノードからばらばらになるということであると考えられます。
3. Local Repair Techniques
3. 局部的修繕のテクニック
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つの異なった方法が説明されます。 回り道LSPは、1〜1つのバックアップ方法で、PLRが別々のバックアップLSPを計算すると呼びました、PLRが保護する各LSPのために。 施設バックアップ方法で、PLRは複数のLSPsを保護するのに使用できる単一の迂回トンネルを作成します。
3.1. One-to-One Backup
3.1. 一対一バックアップ
In the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure. A separate backup LSP is established for each LSP that is backed up.
1〜1つのバックアップ方法に、横切られるラベルで切り換えられた経路が確立される、どこかのオリジナルのLSP、リンクかノード障害のポイントの川下。 別々のバックアップLSPは支援される各LSPのために設立されます。
[R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ /
[R6]----[R7]----[R8]------[R9]
[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、-、R5] R1のものがバックアップをとる>R4->: [R1、-、>R6->、R7、-、R3] R2のものがバックアップをとる>R8->: [R2->、R7、-、R4] R3のものがバックアップをとる>R8->: [R3->、R8、-、R5] R4のものがバックアップをとる>R9->: [R4、-、>R9->、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.
Example1の簡単なトポロジーでは、保護されたLSPがR1からR5まで走ります。 R2はR4で保護されたLSPと合併する部分的なバックアップLSPを作成するのによるユーザ交通保護に提供できます。 私たちが1〜1部分的なバックアップLSPについて言及する、[R2、-、>R7->、R8、-、>R4] 回り道として。
To protect an LSP that traverses N nodes fully, there could be as many as (N - 1) detours. Example 1 shows the paths for the detours necessary to protect fully the LSP in the example. To minimize the number of LSPs in the network, it is desirable to merge a detour back to its protected LSP, when feasible. When a detour LSP intersects its protected LSP at an LSR with the same outgoing interface, it will be merged.
Nノードを完全に横断するLSPを保護するために、(N--1)が迂回するのと同じくらい多くがあるかもしれません。 例1は例にLSPを完全に保護するのに必要な回り道のために経路を示しています。 ネットワークにおける、LSPsの数を最小にするために、保護されたLSPに回り道を合併して戻すのは望ましいです、可能であるときに。 回り道LSPが交差していると、同じくらいが外向的のLSRの保護されたLSPは連結して、それは合併されるでしょう。
Pan, et al. Standards Track [Page 6] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[6ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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は地方の回り道に交通を向け直します。 例えば、リンクである、[R3] Example1、R2のやり損ないがそうするR2->がR1からリンクに沿った保護されたLSPに受けられた交通を切り換える、[R2、-、>R7]、R2が回り道を作成したとき、ラベルを使用するのは受信されました。 R4がR2の回り道にラベルを提供している状態で交通を受けるとき、R4はリンク[R4-R5]にその交通を切り換えるでしょう、保護されたLSPのためにR5から受け取られたラベルを使用して。 どんなポイントでも、ラベルスタックの深さは回り道の結果、増加しません。 R2が回り道を使用している間、交通が経路を取る、[R1->、R2、-、>R7->、R8、-、>R4->、R5]
3.2. Facility Backup
3.2. 施設バックアップ
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を作成することの代わりに、LSPsの1セットを支援するのに役立つ独身の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.
迂回トンネルが横切られなければならない、どこかのオリジナルのLSP(s)の経路、PLRの川下。 当然、これは何らかの一般的な川下のノードを通り抜けるものへのその迂回トンネルを通って支援されるLSPsのセットを抑制します。 局部的修繕のポイントを通してまた、迂回トンネルにかかわる施設を使用しないこの一般的なノードを通るすべてのLSPsがLSPsのこのセットの候補です。
[R8]
\
[R1]---[R2]----[R3]-----[R4]---[R5]
\ / \
[R6]===[R7] [R9]
[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]
保護されたLSP1: [R1->、R2、-、>R3->、R4、-、>R5] 保護されたLSP2: [R8、-、>R2->、R3、-、>R4] 保護されたLSP3: [R2->、R3、-、R9] 迂回LSPがトンネルを堀る>R4->: [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.
Example2では、R2がリンクの失敗から守る迂回トンネルを建設した、[R2、-、>R3] そして、ノード[R3]。 倍増している線はこのトンネルを表します。 このテクニックはスケーラビリティ改良を提供します、また、R1、R2、またはR8のどれかからR4のどれかまでのLSPs、R5、またはR9を保護するのに同じ迂回トンネルを使用できるので。 例2は保護に同じ迂回トンネルを使用している3異なった保護されたLSPsについて説明します。
Pan, et al. Standards Track [Page 7] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[7ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
As with the one-to-one method, there could be as many as (N-1) bypass tunnels to fully protect an LSP that traverses N nodes. However, each of those bypass tunnels could protect a set of LSPs.
1〜1つの方法なら、(N-1)迂回がNノードを横断するLSPを完全に保護するためにトンネルを堀るのと同じくらい多くがあるかもしれません。 しかしながら、それぞれのそれらの迂回トンネルはLSPsの1セットを保護するかもしれません。
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は適切な迂回トンネルに交通を向け直します。 例えば、リンクである、[R3] Example2、R2のやり損ないがそうするR2->が保護されたLSPの上のR1からリンクに受けられた交通を切り換える、[R2、-、>R6] ラベルは保護されたLSPを示すためにR4に解釈されるもののために切り換えられるでしょう、そして、次に、迂回トンネルのラベルは向け直されたパケットのラベルスタックに押されるでしょう。 終わりから二番目のホップの飛び出しが使用されていると、ラベルがパケットが続くことになっている保護されたLSPを示していて、Example2のマージポイント(R4)は向け直されたパケットを受けるでしょう。 終わりから二番目のホップの飛び出しが使用されていないと、R4は、パケットが続くことになっている保護されたLSPを決定するために迂回トンネルのラベルを飛び出させて、ラベル下部を調べるでしょう。 R2が保護されたLSP1に迂回トンネルを使用しているとき、交通が経路を取る、[R1->、R2、-、>R6->、R7、-、>R4->、R5]、。 迂回トンネルはR2とR4との接続です。
4. RSVP Extensions
4. RSVP拡張子
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、およびDETOURを定義します。 これらの新しい物は彼らを認識しないLSRsと互換性があった状態で後方です([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物は、帯域幅とノード保護機能を支持するために広げられます。
4.1. FAST_REROUTE Object
4.1. 速い_は物を別ルートで送ります。
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メッセージに挿入するだけでよくて、川下のLSRsによって変えられてはいけません。 FAST_REROUTE物には、以下の形式があります:
Pan, et al. Standards Track [Page 8] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[8ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
Class-Num = 205
C-Type = 1
クラスヌム=205C-タイプ=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 |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | 長さ(バイト)| クラスヌム| C-タイプ| +-------------+-------------+-------------+-------------+ | セットアップPrio| Prioを持ってください。| ホップ限界| 旗| +-------------+-------------+-------------+-------------+ | 帯域幅| +-------------+-------------+-------------+-------------+ | いずれも含んでいます。| +-------------+-------------+-------------+-------------+ | いずれも除きます。| +-------------+-------------+-------------+-------------+ | すべてを含んでいます。| +-------------+-------------+-------------+-------------+
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は最優先です。 このセッションが別のセッションを先取りできるかどうか決める際にセットアップPriorityは使用されます。 優先権の用法に関して[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
1〜1つのバックアップが望んでいた0×01
Requests protection via the one-to-one backup method.
1〜1つのバックアップ方法で保護を要求します。
Pan, et al. Standards Track [Page 9] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[9ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
0x02 Facility Backup Desired
望まれていた0×02施設バックアップ
Requests protection via the facility backup method.
施設バックアップ方法で保護を要求します。
Bandwidth
帯域幅
Bandwidth estimate; 32-bit IEEE floating point integer, in
bytes per second.
帯域幅見積り。 1秒あたりのバイトで表現される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.
1セットの属性を表す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.
1セットの属性を表す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.
1セットの属性を表す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.
Class-ヌム(11)の2高位のビットが物がそれを無視して、変わりがない状態でそれを前方へパスするのを理解していないノードを引き起こします。
For informational purposes, a different C-Type value and format for the FAST_REROUTE object are specified below. This is used by legacy implementations. The meaning of the fields is the same as that described for C-Type 1.
情報の目的として、FAST_REROUTE物のための異なったC-タイプ値と形式は以下で指定されます。 これは遺産実現で使用されます。 分野の意味はC-タイプ1のために説明されたそれと同じです。
Pan, et al. Standards Track [Page 10] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[10ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
Class-Num = 205
C-Type = 7
クラスヌム=205C-タイプ=7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | 長さ(バイト)| クラスヌム| C-タイプ| +-------------+-------------+-------------+-------------+ | セットアップPrio| Prioを持ってください。| ホップ限界| 予約されます。| +-------------+-------------+-------------+-------------+ | 帯域幅| +-------------+-------------+-------------+-------------+ | いずれも含んでいます。| +-------------+-------------+-------------+-------------+ | いずれも除きます。| +-------------+-------------+-------------+-------------+
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
未知のC-タイプは[RSVP]セクション3.10で指定されるように扱われるべきです。
4.2. DETOUR Object
4.2. 回り道物
The DETOUR object is used in the one-to-one backup method to identify detour LSPs.
DETOUR物は回り道LSPsを特定する1〜1つのバックアップ方法で使用されます。
4.2.1. DETOUR Object for IPv4 Address
4.2.1. IPv4アドレスのために物を迂回してください。
Class-Num = 63
C-Type = 7
クラスヌム=63C-タイプ=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 |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | 長さ(バイト)| クラスヌム| C-タイプ| +-------------+-------------+-------------+-------------+ | PLR_ID1| +-------------+-------------+-------------+-------------+ | _ノード_ID1を避けてください。| +-------------+-------------+-------------+-------------+ // .... // +-------------+-------------+-------------+-------------+ | PLR_ID n| +-------------+-------------+-------------+-------------+ | _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の上のどんなローカルアドレスも使用できます。
Pan, et al. Standards Track [Page 11] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[11ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
Avoid_Node_ID (1 - n)
_ノード_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によって使用されます。
4.2.2. DETOUR Object for IPv6 Address
4.2.2. IPv6アドレスのために物を迂回してください。
Class-Num = 63
C-Type = 8
クラスヌム=63C-タイプ=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) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | 長さ(バイト)| クラスヌム| C-タイプ| +-------------+-------------+-------------+-------------+ | PLR_ID1| +-------------+-------------+-------------+-------------+ | PLR_ID1(続けられています)| +-------------+-------------+-------------+-------------+ | PLR_ID1(続けられています)| +-------------+-------------+-------------+-------------+ | PLR_ID1(続けられています)| +-------------+-------------+-------------+-------------+ | _ノード_ID1を避けてください。| +-------------+-------------+-------------+-------------+ | _ノード_ID1(続けられています)を避けてください。| +-------------+-------------+-------------+-------------+ | _ノード_ID1(続けられています)を避けてください。| +-------------+-------------+-------------+-------------+ | _ノード_ID1(続けられています)を避けてください。| +-------------+-------------+-------------+-------------+ // .... // +-------------+-------------+-------------+-------------+
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)
_ノード_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
PLRが避けようとしている即座の川下のノードを特定するIPv6の128ビットのユニキャストホスト・アドレス。 川下のノードの上のどんなローカルアドレスも使用できます。 この分野はそうです。
Pan, et al. Standards Track [Page 12] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[12ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
mandatory and is used by the MP for the merging rules discussed
below.
そして、義務的である、以下で議論した合併している規則に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.
1組以上の(PLR_Avoid_Node_ID(ID))エントリーがDETOUR物にあることができます。 操作がそれぞれ回り道合併するのが、次々と必要であるなら、Detour Merge Pointはその後の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".
Class-ヌムの高位のビットはゼロです。 DETOUR物を支えないLSRsは、DETOUR物を含むどんなPathメッセージも拒絶して、PLRに通知するためにPathErrを送らなければなりません。 このPathErr SHOULD、フォーム"0bbbbbbb"のClass-ヌムと共に[RSVP]で未知の物に指定されるように、発生してください。
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
未知のC-タイプは[RSVP]セクション3.10で指定されるように扱われるべきです。
4.3. SESSION_ATTRIBUTE Flags
4.3. セッション_属性旗
To request bandwidth and node protection explicitly, two new flags are defined in the SESSION_ATTRIBUTE object.
明らかに帯域幅とノード保護を要求するために、2個の新しい旗がSESSION_ATTRIBUTE物で定義されます。
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has the following flags defined [RSVP-TE]:
C-タイプ1と7の両方に関しては、現在持っている_ATTRIBUTEが以下の旗を反対させるSESSIONは[RSVP-TE]を定義しました:
Local protection desired: 0x01
地方の保護は望んでいました: 0×01
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
必要であると録音をラベルしてください: 0×02
This flag indicates that label information should be included
when doing a route record.
この旗は、ルート記録をするとき、ラベル情報が含まれるべきであるのを示します。
SE Style desired: 0x04
望まれていたSE様式: 0×04
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メッセージで応じるとき、トンネル出口ノードSHOULDはSE様式を使用します。 コースを変更するよう速く要求するとき、ギヤエンドLSR SHOULDはこの旗を設定します。 これは1〜1つのバックアップ方法の経路特有の方法に必要ではありません。
Pan, et al. Standards Track [Page 13] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[13ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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に示します。 保証される帯域幅は保護されたLSPのものです、FAST_REROUTE物が全くPATHメッセージに含まれていないなら。 FAST_REROUTE物がPATHメッセージにあるなら、そこに指定された帯域幅は保証されることになっています。
Node protection desired: 0x10
望まれていたノード保護: 0×10
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に示します。
4.4. RRO IPv4/IPv6 Sub-object Flags
4.4. RRO IPv4/IPv6サブオブジェクト識別子
To report whether bandwidth and/or node protection are provided as requested, we define two new flags in the RRO IPv4 sub-object.
要求された通り帯域幅、そして/または、ノード保護を提供するか否かに関係なく、報告するために、私たちはRRO IPv4サブ物の2個の新しい旗を定義します。
The RRO IPv4 and IPv6 address sub-objects currently have the following flags defined [RSVP-TE]:
現在サブ物のRRO IPv4とIPv6アドレスには、定義された以下の旗[RSVP-TE]があります:
Local protection available: 0x01
利用可能な地方の保護: 0×01
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
使用中の地方の保護: 0×02
Indicates that a local repair mechanism is in use to maintain
this tunnel (usually in the face of an outage of the link it
was previously routed over, or an outage of the neighboring
node).
局部的修繕メカニズムがこのトンネル(通常それが以前に発送されたリンクの供給停止、または隣接しているノードの供給停止に直面して)を維持するために使用中であることを示します。
Two new flags are defined:
2個の新しい旗が定義されます:
Bandwidth protection: 0x04
帯域幅保護: 0×04
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
保護されたLSPにFAST_REROUTE物で指定される必要な帯域幅か保護されたLSPの帯域幅を供給するために保証されるバックアップ道があるとき、PLRはこのビットを設定するでしょう、FAST_REROUTE物が全く含まれていなかったなら。 必要な帯域幅が保証されるときはいつも、PLRはこれを設定するかもしれません。 必要な帯域幅が保証されるとき、PLR MUSTはこの旗を設定します。
Pan, et al. Standards Track [Page 14] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[14ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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.
そして、「帯域幅保護必要な」旗はSESSION_ATTRIBUTE物に設定されました。 要求された帯域幅が保証されないなら、PLR MUST NOTはこの旗を設定します。
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 MUSTはこの旗を設定します。 ノード保護が提供されないなら、PLR MUST NOTはこの旗を設定します。 したがって、PLRがリンク保護バックアップ道をセットアップできるだけであると、「利用可能な地方の保護」ビットは設定されるでしょうが、「ノード保護」ビットはきれいにされるでしょう。
5. Head-End Behavior
5. ギヤエンドの振舞い
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 MUSTはSESSION_ATTRIBUTE物に「地方の保護必要な」旗を設定するか、またはPATHメッセージ、または両方にFAST_REROUTE物を含んでいます。 「望まれていた地方の保護」はSESSION_ATTRIBUTE物のSHOULDでいつも弛みます。設定されます。 ギヤエンドLSRがFAST_REROUTE物に合図するなら、Pathがリフレッシュするので、それを格納しなければなりません。
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.
SESSION_ATTRIBUTE物の保護されたLSP MUSTセットのギヤエンドLSR「望まれていたラベル録音」旗。 これは施設バックアップ方法の使用を容易にします。 ノード保護が望まれているなら、ギヤエンド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
ギヤエンドLSRが、1〜1つのバックアップ方法が保護されたLSPに使用されることを望んでいるなら、ギヤエンドLSRはFAST_REROUTE物を含んで、「1〜1つのバックアップ必要な」旗を設定するはずです。 if
Pan, et al. Standards Track [Page 15] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[15ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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.
保護されたLSPが施設バックアップ方法で保護されるというギヤエンドのLSR願望、次に、ギヤエンド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.
保護されたLSP MUSTサポートのギヤエンドLSRのときに、追加旗は、サブ物を設定されるセクション4.4で定義するか、またはRRO IPv4とIPv6できれいにします。 保護されたLSP MUSTのギヤエンドLSRはRRO Labelサブ物を支えます。
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がそれを決定するなら、地方の保護は新たに望まれていて、これはSHOULDです。以前開閉していることを通して、合図されます。
6. Point of Local Repair (PLR) Behavior
6. 局部的修繕(PLR)の振舞いのポイント
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.
FAST_REROUTE物、「望まれていた地方の保護」が「望まれていた録音とラベルする」PLR SHOULDサポート、「望まれていたノード保護」、および「望まれていた帯域幅保護」はRRO IPv4とIPv6サブ物でSESSION_ATTRIBUTE物、「利用可能な地方の保護」、「使用中の地方の保護」、「帯域幅保護」、および「ノード保護」旗で弛みます。 PLR MAYは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.
「地方の保護必要な」旗がSESSION_ATTRIBUTE物に設定されるなら、PLR MUSTは、LSPが地方の保護を求めたと考えます、そして、FAST_REROUTE物は含まれています。 含まれています、PLR SHOULDが「望まれていた1〜もの」が設定されるなら1〜1つの保護を提供して、それがSHOULDであると考えるという_REROUTEが、反対することであるFASTであるなら、「施設バックアップ必要な」旗が設定されるなら施設バックアップを提供すると考えてください。 「ノード保護必要な」旗が設定されるなら、PLR SHOULDはノード保護を提供しようとします。 これが可能でないなら、PLR SHOULDはリンク保護を提供しようとします。 「保護が保証した帯域幅」旗が設定されるなら、PLR SHOULDは帯域幅保証を提供しようとします。 これが可能でないなら、PLR SHOULDは完全な帯域幅の保証なしでバックアップを提供しようとします。
Pan, et al. Standards Track [Page 16] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[16ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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 MUSTは対応する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 MUSTは「利用可能な地方の保護」旗を設定します。 設立されないなら1〜1つのバックアップLSPか迂回トンネルが存在しているか、1〜1LSPと迂回トンネルであるならPLRがRROのIPv4(または、IPv6)アドレスサブ物で“DOWN"状態では、「利用可能な地方の保護」旗をきれいにしなければならないということであり、アップデートされた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 MUSTは「使用中の地方の保護」旗をきれいにします。
- 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 SHOULDは「ノード保護」旗を設定します、そして、経路がそうしないなら、PLR SHOULDは「ノード保護」旗をきれいにします。 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 SHOULDは「帯域幅保護」旗を設定します、そして、経路がそうしないなら、PLR SHOULDは「帯域幅保護」旗をきれいにします。 SESSION_ATTRIBUTE物に「帯域幅保護必要な」旗を設定したなら、これをしなければなりません。
6.1. Signaling a Backup Path
6.1. バックアップ道に合図します。
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. 明白に仲間は彼らのバックアップ道があるLSPsを保護しました。
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状態を維持します。
Pan, et al. Standards Track [Page 17] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[17ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects [RSVP-TE]. The relevant fields are as follows.
LSPトンネルはSESSIONとSENDER_TEMPLATE物[RSVP-TE]の組み合わせで特定されます。 関連分野は以下の通りです。
IPv4 (or IPv6) tunnel end point address
IPv4(または、IPv6)トンネルエンドポイントアドレス
IPv4 (or IPv6) address of the egress node for the tunnel.
トンネルのための出口ノードのIPv4(または、IPv6)アドレス。
Tunnel ID
トンネルID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
16ビットの識別子はトンネルの人生の間、SESSIONでその残り定数を使用しました。
Extended Tunnel ID
拡張Tunnel 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でその残り定数を使用しました。 通常、それはすべてのゼロに設定されます。 イングレス出口組にSESSIONの範囲を狭くしたがっているイングレスノードはグローバルにユニークな識別子としてそれらの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.
16ビットの識別子はSENDER_TEMPLATEとFILTERで_SPECを使用しました。(送付者がそれ自体とリソースを共有するのを許容するためにSPECを変えることができます)。
The first three of these are in the SESSION object and are the basic identification for the tunnel. Setting the "Extended Tunnel ID" to an IP address of the head-end LSR allows the scope of the SESSION to be narrowed to only LSPs sent by that LSR. A backup LSP is considered part of the same session as its protected LSP; therefore these three cannot be varied.
これら最初の3つは、SESSION物にあって、トンネルのための基本的な識別です。 「拡張Tunnel ID」をギヤエンドLSRのIPアドレスに設定するのは、SESSIONの範囲がそのLSRによって送られたLSPsだけに狭くされるのを許容します。 バックアップLSPは保護されたLSPと同じセッションの一部であると考えられます。 したがって、これらの3を変えることができません。
The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same SESSION may be protected and may take different routes; this is common when a tunnel is rerouted using make-before-break. A backup path must be clearly identified with its protected LSP to allow correct merging and state treatment. Therefore, a backup path must inherit its LSP ID from the associated protected LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE objects that could be varied between a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE.
最後の2はSENDER_TEMPLATEにあります。 同じSESSIONの複数のLSPsが保護されて、異なったルートを取るかもしれません。 使用がトンネルに以前開閉していた状態で別ルートで送られるとき、これは一般的です。 正しい合併と州の処理を許すために明確にバックアップ道を保護されたLSPと同一視しなければなりません。 したがって、バックアップ道は関連保護されたLSPからLSP IDを引き継がなければなりません。 したがって、SESSIONとSENDER_TEMPLATE物におけるバックアップ道と保護されたLSPの間で変えることができた唯一の分野がSENDER_TEMPLATEの「IPv4(または、IPv6)トンネル送付者アドレス」です。
Pan, et al. Standards Track [Page 18] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[18ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
There are two different methods to uniquely identify a backup path, described below.
以下で説明されて、唯一バックアップ道を特定する2つの異なった方法があります。
6.1.1. Backup Path Identification: Sender Template-Specific
6.1.1. 経路識別のバックアップをとってください: 送付者テンプレート詳細
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.
このアプローチでは、SESSION物と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].
送付者のテンプレート特有のアプローチが使用されているとき、保護されたLSPsとバックアップ経路SHOULDはShared Explicit(SE)スタイルを使用します。 これは複数のバックアップ道を平等に割り当てる帯域幅を許容します。 EROであるときに、バックアップ道と保護されたLSP MAYがDetour Merge Pointsによって合併されて、MPから出口まで、同じくらいがあります。各指定されるとして[RSVP-TE]で合併するべきLSPで。
6.1.2. Backup Path Identification: Path-Specific
6.1.2. 経路識別のバックアップをとってください: 経路特有です。
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.
このアプローチでは、むしろ、実現は、バックアップ道と保護されたLSPへのPATHメッセージを見分けるのにSESSIONかSENDER_TEMPLATE物を変えるより新しい物、DETOUR物を使用します。
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メッセージでのDETOUR物の存在はバックアップ道を意味します。 SESSION_ATTRIBUTE物のFAST_REROUTE物、そして/または、「要求された地方の保護」旗の存在は保護されたLSPを示します。
In the path message-specific approach, an LSR merges Path messages that are received with the same SESSION and SENDER_TEMPLATE objects and that also have the same next-hop object. Without this behavior, it would be impossible to associate the multiple RESV messages with the backup paths. However, this merging behavior reduces the total number of RSVP states inside the network at the expense of merging LSPs with different EROs.
経路のメッセージ特有のアプローチでは、LSRは同じSESSIONとSENDER_TEMPLATE物で受け取られて、また同じ次のホップ物を持っているPathメッセージを合併します。 この振舞いがなければ、複数のRESVメッセージをバックアップ道に関連づけるのは不可能でしょう。 しかしながら、異なったEROsにLSPsを合併することを犠牲にしてこの合併している振舞いはネットワークの中でRSVP州の総数を減少させます。
Pan, et al. Standards Track [Page 19] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[19ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
6.2. Procedures for Backup Path Computation
6.2. バックアップ経路計算のための手順
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(規制ベースのShortest Path First)計算を使用し終わることができます。 この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が通り抜ける上流のuni方向のリンク。 この情報は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.
- 適用されるべきリンク属性フィルタ。 FAST_REROUTE物からこれらを得ます、それが別の方法でPATHメッセージか、SESSION_ATTRIBUTE物から含まれているなら。
- 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.
- 使用されるべき帯域幅はFAST_REROUTE物で見つけられます、それが別の方法でPATHメッセージ、またはSESSION_ATTRIBUTE物に含まれているなら。 ローカルの方針は、予約されるように帯域幅を変更するかもしれません。
- The hop-limit, if a FAST_REROUTE object was included in the PATH
message.
- _ホップ限界であり、REROUTE物はFASTであるなら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.
- 回り道LSPsに関しては、目的地は保護されたLSPの末端であるに違いありません。 迂回トンネル(セクション7)に関しては、目的地はMPのアドレスであるに違いありません。
Pan, et al. Standards Track [Page 20] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[20ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
- When one-to-one protection is set up by using the path-specific
method, a detour MUST not traverse the upstream links of the
protected LSP in the same direction. This prevents the
possibility of early merging of the detour into the protected
LSP. When one-to-one protection is set up using the sender-
template-specific method, a detour should not traverse the
upstream links of the protected LSP in the same direction. This
prevents sharing the bandwidth between a protected LSP and its
backup upstream of the failure where the bandwidth would be used
twice in the event of a failure.
- 1〜1つの保護が経路特有の方法を使用することによってセットアップされるとき、回り道は保護されたLSPの上流のリンクを同じ方向に横断してはいけません。 これは回り道の早い合併の可能性を保護されたLSPに防ぎます。 1〜1つの保護が送付者のテンプレート特有の方法を使用するのに設定されるとき、回り道は保護された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がどんな理由でもバックアップ道を持って来ることができないなら、それは後で再試行の計画をしなければなりません。
6.3. Signaling Backups for One-to-One Protection
6.3. 1〜1のためのシグナリングバックアップ保護
Once a PLR has decided to protect an LSP locally with one-to-one backup and has identified the desired path, it signals for the detour.
それは、回り道のためにPLRが一度、1〜1つのバックアップで局所的にLSPを保護すると決めて、必要な経路を特定したことがあると合図します。
The following describes the transformation to be performed upon the protected LSP's PATH message to create the detour LSP's PATH message.
以下は、回り道LSPの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 MUSTはSENDER_TEMPLATEの「IPv4(または、IPv6)トンネル送付者アドレス」を保護されたLSPに使用されるそれと同じでないPLRに属すアドレスに変えます。 さらに、DETOUR物はPATHメッセージに追加されるかもしれません。
- If the path-specific method is to be used, then the PLR MUST add
a DETOUR object to the PATH message.
- 経路特有の方法が使用されていることであるなら、PLR MUSTはDETOUR物をPATHメッセージに追加します。
Pan, et al. Standards Track [Page 21] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[21ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
- 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物のSHOULDのPath MessageがFAST_REROUTE物を含んで、EROが完全に厳しいというわけではないか、そして、いくらかInclude、Excludeいずれ、およびIncludeすべて、分野、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 MUSTはEXPLICIT_ROUTE物を出口に向かって発生させます。 まず最初に、PLRは、Merge Pointに属す最初のアドレスに先行しながら、すべてのサブ物を取り除かなければなりません。 そして、PLR SHOULDはPLRとMPの間の必要なバックアップ道に対応するサブ物を加えます。
- The SENDER_TSPEC object SHOULD contain the bandwidth information
from the received FAST_REROUTE object, if included in the
protected LSP's PATH message.
- SENDER_TSPEC物のSHOULDは容認されたFAST_REROUTE物からの帯域幅情報を含んでいます、保護されたLSPのPATHメッセージに含まれているなら。
- 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.
- 回り道LSPsは保護された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.
回り道LSPsは通常のLSPsのように作動します。 いったん回り道経路が首尾よく計算されて、回り道LSPが設立されると、PLRは再び回り道ルートを計算する必要はありません、(1) FAST_REROUTEの内容が変化したか、または(2) 保護されたLSPのための川下のインタフェース、そして/または、nexthopルータが変化していない場合。 PLRはいつでもrecompute回り道ルートがそうするかもしれません。
6.3.1. Make-before-Break with Detour LSPs
6.3.1. 以前、回り道LSPsと共に開閉してください。
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.
送付者のテンプレート特有の方法が使用されているなら、以前回り道LSPsと共に開閉するのは可能です。 これはPLR(保護されたLSPのSENDER_TEMPLATEで使用されなかった)に属す2つの異なったIPアドレスを使用し終わっています。 現在の回り道LSPがSENDER_TEMPLATEにおける最初のIPアドレスを使用するなら、SENDER_TEMPLATEにおける2番目のIPアドレスを使用することによって、新しい回り道LSPは合図されるべきです。 いったん新しい回り道LSPを作成すると、現在の回り道LSPを取りこわすことができます。 これらのIPアドレスの使用を交替することによって、現在の、そして、新しい回り道LSPsは川下のLSRsに異なったSENDER_TEMPLATESとその結果異なった状態を持つでしょう。
Pan, et al. Standards Track [Page 22] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[22ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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.
この以前開閉しているメカニズム(代わりにDETOUR物でPLR IPアドレスを変える)は経路特有の方法で可能ではありません、彼らが普通の次のホップを共有するなら新しくて現在の回り道LSPsへのPATHメッセージが合併されているとき。
6.3.2. Message Handling
6.3.2. メッセージハンドリング
LSRs must process the detour LSPs independently of the protected LSPs to avoid triggering the LSP loop detection procedure described in [RSVP-TE].
LSRsは、保護されたLSPsの如何にかかわらず[RSVP-TE]で説明されたLSP輪の検出手順の引き金となるのを避けるために回り道LSPsを処理しなければなりません。
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 MUSTは保護へのメッセージと回り道LSPsを混ぜません。 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メッセージを受け取るとき、それは保護と回り道LSPsの両方を削除しなければなりません。 PathTearメッセージは、ともにLSPsを保護して、迂回するために伝播されなければなりません。 エラー条件の間、LSRsは失敗経路で問題を解決するメッセージをResvTearに送るかもしれません。 PLRノードが保護されたLSPのために川下からResvTearメッセージを受け取るとき、回り道が上がっている限り、さらに上流へResvTearメッセージを送ってはいけません。 PathErrsは同様に扱われるべきです。
6.3.3. Local Reroute of Traffic onto Detour LSP
6.3.3. ローカルは回り道LSPに交通のコースを変更します。
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 MUSTは保護されたLSPの正常な出ているセグメントの代わりに急速に保護されたLSPのバックアップLSPにパケットを切り換えます。 この方法の目標は10年代の中でミリセカンドについてリダイレクションに作用することです。
L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | | L44
| L47 |
R6----------------R7
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。 迂回するために、再直接です。
Pan, et al. Standards Track [Page 23] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[23ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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.
R3] やり損ない、R2がそうするR2->はそうします。リンクであることでのコネExample3、[以下。 どんな交通もリンクの上に受信された、[R1、-、>R2]、ラベルで、L32をリンクに送るだろう、[R2、-、>R6]、オンの代わりにラベルL46(回り道LSPに沿った)に、リンクしてください、[R3、-、>R4] ラベルL34(保護されたLSPに沿った)と共に。 マージポイントR4が、パケットがリンクの上に受信されたと認めるだろう、[R7、-、>R4]、ラベルで、L44をリンクに送るべきである、[R4、-、>R5] ラベルL35とそれで、それらは保護されたLSPに合併されるべきです。
6.4. Signaling for Facility Protection
6.4. 施設保護のために合図すること。
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つ以上の迂回トンネルを使用するかもしれません。 これらの迂回トンネルは、あらかじめ、設立されるか、または新しい保護されたLSPsが合図されるとき、ダイナミックに作成されるかもしれません。
6.4.1. Discovering Downstream Labels
6.4.1. 川下のラベルを発見します。
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は、パケットがそのラベルで受信されたのをMPに示すラベルが保護されたLSPに沿って切り換えられるべきであることを決定しなければなりません。 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 MUSTは、LSPsのためのSESSION_ATTRIBUTE物の「録音が要求したラベル」旗が地方の保護を要求するように設定します。 これは、すべてのLSRsが、彼らのINBOUNDラベルを記録して、ラベルが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が1インタフェースあたりのラベル空間を使用すると、PLRは、適切なMPラベルを発見するために、失敗の前のその迂回トンネルを通してメッセージ(それぞれが迂回トンネルを使用することでLSPを保護したので)をPathに送らなければなりません。 セクション6.4.3未満にはこれのためのシグナリング手順があります。
6.4.2. Procedures for the PLR before Local Repair
6.4.2. 局部的修繕の前のPLRのための手順
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物で指定されたか否かに関係なく、要求されているものであったのを使用するために迂回トンネルを選択するはずです。 aがLSPを保護したので、LSPが上に第一セットであるときに、迂回トンネルの選択はPLRによって実行されます。
Pan, et al. Standards Track [Page 24] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[24ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
6.4.3. Procedures for the PLR during Local Repair
6.4.3. 局部的修繕の間の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は変わりがありません: 「地方の保護必要で」、「帯域幅保護必要で」、および「ノード保護必要」はSHOULDに旗を揚げさせます。クリアされます。 「望まれていたラベル録音」は変更されるかもしれません。
- 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 MUSTはEXPLICIT_ROUTE物を出口に向かって発生させます。 詳細なERO処理は以下で説明されます。
- The RRO object may have to be updated as described in Section
6.5.
- セクション6.5で説明されるようにRRO物をアップデートしなければならないかもしれません。
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はバックアップトンネルを通してPath、PathTear、およびResvConfにメッセージを送ります。 MPは直接RSVP_HOP物のアドレスにそれらを送ることによって、Resv、ResvTear、およびPathErrにメッセージを送ります、[RSVP]で指定されるように。
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ラベルが使用することを決定する失敗の前にバックアップに合図するのが必要であるなら、同じ当時のPathメッセージを送ります。 この場合、PLR SHOULDは、ノーマルルートに沿って保護されたLSPへのメッセージをPathに送り続けています。 PathTearメッセージはノーマルルートに沿って1つを送ってコピーされるべきでした、そして、1つは迂回トンネルを通って発信しました。 MPは、ResvとResvTearメッセージをコピーして、保護されたLSPのRSVP_HOP物によって示されたPLRとLSRの両方にそれらを送るべきです。
Pan, et al. Standards Track [Page 25] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[25ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
6.4.4. Processing Backup Tunnel's ERO
6.4.4. 処理バックアップトンネルのERO
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処理規則が従われているなら、Merge Pointは最初のサブ物を調べて、おそらく、それ(悪い初期のサブ物)を拒絶するでしょうに。 これは変更されていないEROが迂回しているノード(NNHOP Bypass Tunnelの場合における)か現在下にあるインタフェース(NHOP Backup Tunnelの場合における)のIPアドレスを含むかもしれないからです。 この理由で、迂回トンネルを通してPathメッセージを送る前に、PLRは以下のERO手順を呼び出します。
Sub-objects belonging to abstract nodes that precede the Merge
Point are removed, along with the first sub-object belonging to
the MP. A sub-object identifying the Backup Tunnel destination is
then added.
Merge Pointに先行する抽象的なノードに属すサブ物を取り除きます、MPのものである最初のサブ物と共に。 そして、Backup Tunnelの目的地を特定するサブ物は加えられます。
More specifically, the PLR MUST:
より多く、明確にPLR MUST:
- remove all the sub-objects proceeding the first address
belonging to the MP, and
- そしてMPのものである最初のアドレスを続かせながらすべてのサブ物を取り除いてください。
- replace this first MP address with an IP address of the MP.
(Note that this could be same address that was just removed.)
- この最初のMPアドレスをMPのIPアドレスに取り替えてください。 (これがただ取り除かれた同じアドレスであるかもしれないことに注意してください。)
6.5. PLR Procedures during Local Repair
6.5. 局部的修繕の間のPLR手順
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 MUSTはそれが「使用中の地方の保護」を設定することによってRROに挿入したIPv4かIPv6サブ物をアップデートします、そして、「利用可能な地方の保護」は弛みます。
6.5.1. Notification of Local Repair
6.5.1. 局部的修繕の通知
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に再合図できるように、失敗を知らなければなりません。
Pan, et al. Standards Track [Page 26] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[26ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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 SHOULDは「通知する」(エラーコード=25)のエラーコードとss00 cccc cccc cccc、どこss=00、およびサブコード=3の誤り値の分野と共にPath Errorメッセージを送るか(「トンネルは局所的に修理した」)([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が排他的に別の領域で失敗で知識があるようになるPath Errorメッセージを当てにしなければならないことに注意してください。
6.5.2. Revertive Behavior
6.5.2. Revertiveの振舞い
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.
- グローバルなrevertiveモード: それぞれのトンネルのギヤエンドLSRは失敗したリソースを使用したTE LSPsを再最適化するのに責任があります。 数個の潜在的「再-最適化」引き金があります: RSVPエラーメッセージ、OSPF LSAsかイシスLSPsの点検、およびタイマ。 失敗が検出されるとすぐに、この再最適化の過程が続くかもしれないことに注意してください。 それは失敗したリソースの回復に結ばれません。
- 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.
- ローカルのrevertiveモード: リソースはそれを検出すると回復します、それぞれ以前はよく回復しているリソースの上に発送されていたTE LSPsに関するPLR再信号。 回復しているリソースに沿って首尾よく再合図されたあらゆるTE LSPは元に戻らされます。
There are several circumstances in which a local revertive mode might not be desirable. In the case of resource flapping (not an uncommon failure type), this could generate multiple traffic disruptions. Therefore, in the local revertive mode, the PLR should implement a means to dampen the re-signaling process in order to limit potential disruptions due to flapping.
ローカルのrevertiveモードが望ましくないかもしれないいくつかの事情があります。 リソースのばたつくこと(珍しい失敗タイプでない)の場合では、これは複数の交通分裂を発生させるかもしれません。 したがって、ローカルのrevertiveモードで、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
ローカルのrevertiveモードで、どんなTE LSPも元に戻らされるでしょう、TE LSP属性に基づくギヤエンドLSRまでにグローバルなrevertiveモードで回復しているリソースを再利用するという決定をして少しも区別なしで。 ギヤエンドが失敗を知っているとき、異なって、より最適の経路に沿って保護されたLSPトンネルを再最適化するかもしれません、それにリソースとTE LSP規制の、より完全な視点があるとき。 これは、それが振り向けられた古いLSPがもう最適でないかもしれないことを意味します。 いくらかのPath Computation ElementでTE LSP経路計算をするかもしれない相互領域LSPの場合では、「再-最適化」の過程がそうすることができることに注意してください。
Pan, et al. Standards Track [Page 27] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[27ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
still be triggered on the Head-End LSP. The local revertive mode is optional.
それでも、Head-終わりのLSPで引き起こされてください。 ローカルのrevertiveモードは任意です。
However, there are circumstances in which the head-end does not have the ability to reroute the TE LSP (e.g., if the protected LSP is pinned down, as may be desirable if the paths are determined by using an off-line optimization tool), or if the head-end does not have the complete TE topology information (depending on the path computation scenario). In those cases, the local revertive mode might be an interesting option.
しかしながら、ギヤエンドに完全なTEトポロジー情報がないなら(経路計算シナリオによって)、ギヤエンドがTE LSP(例えば、経路があるならLSPが望ましいかもしれないようにピンで止められる保護がオフライン最適化ツールを使用することで自決したなら)を別ルートで送る能力を持っていない事情があります。 それらの場合では、ローカルのrevertiveモードはおもしろいオプションであるかもしれません。
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.
モードSHOULDをグローバルにいつもrevertiveする、使用されてください。 「失敗」というリンクかノードが永久に使われなくなっていた状態で取られる施設のためであるかもしれないことに注意してください。 ローカルのrevertiveモードは任意です。 組み合わせに使用されると、グローバルなモードは、「再-最適化」をするために唯一タイマを当てにするかもしれません。 ローカルのrevertiveモードが使用されていないとき、ギヤエンドLSRs SHOULDは、タイムリーな応答をするようにRSVPエラーメッセージ、そして/または、IGP指摘に反応します。
Interoperability: If a PLR is configured with the local revertive mode but the MP is not, any attempt from the PLR to resignal the TE LSP over the restored resource will fail, as the MP will not send any Resv message. The PLR will still refresh the TE LSP over the backup tunnel. The TE LSP will not revert to the restored resource; instead, it will continue to use the backup until it is re-optimized.
相互運用性: PLRがローカルのrevertiveモードによって構成されるか、しかし、MPはそうではありません、どんなPLRから回復しているリソースの上のTE LSPが失敗する「再-信号」までの試み、MPがどんなResvメッセージも送らないとき。 それでも、PLRはバックアップトンネルの上でTE LSPをリフレッシュするでしょう。 TE LSPは回復しているリソースに戻らないでしょう。 それは、代わりに、それが再最適化されるまでバックアップを使用し続けるでしょう。
7. Merge Node Behavior
7. ノードの振舞いを合併してください。
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へのPathメッセージと溶け込まれるバックアップLSPへの1つ以上のメッセージを受け取るなら、LSRはMerge Pointです。 1〜1つのバックアップ方法で、LSRはそれが失敗の前のマージノードであることを意識しています。 施設バックアップ方法で、LSRは、それが失敗が起こって、バックアップLSPのPathメッセージを受け取るまでMerge Pointであることを知らないかもしれません。 したがって、保護されたLSP SHOULDの経路でいつもそれがマージポイントであると仮定することである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メッセージを受け取るとき、Common HeaderのSend_TTLはPathメッセージが輸送されたIPパケットのTTLに合わないかもしれません。 これは予想された振舞いです。
7.1. Handling Backup Path Messages before Failure
7.1. 失敗の前の取り扱いバックアップ経路メッセージ
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.
Merge Pointが失敗の前にバックアップ道へのPathメッセージを受け取る2つの事情があります。 前者の場合、PLRが1〜1つのバックアップ方法で地方の保護を提供しているなら、回り道に合図されて、MPは適切に扱わなければなりません。
Pan, et al. Standards Track [Page 28] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[28ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
In this case, the backup LSP may be signaled via the sender template-specific method or via the path-specific method.
この場合、送付者のテンプレート特有の方法か経路特有の方法でバックアップLSPは合図されるかもしれません。
In the second case, if the Merge Point does not provide labels global to the MP and record them in a Label sub-object of the RRO, or if the PLR does not use such recorded information, the PLR may signal the backup path as described in Section 6.4.1. This will determine the label to use if the PLR is providing protection according to the facility backup method. In this case, the backup LSP is signaled via the sender template-specific method.
2番目の場合では、PLRがそのような記録情報を使用しないなら、Merge PointがMPにとって、グローバルなラベルを供給して、RROのLabelサブ物にそれらを記録しないなら、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がもう使用されないのを示しません。
7.1.1. Merging Backup Paths using the Sender Template-Specific Method
7.1.1. 送付者のテンプレート特有の方法を使用することでバックアップ道を合併します。
An LSR may receive multiple Path messages for one or more backup LSPs and, possibly, for the protected LSP. Each of these Path messages will have a different SENDER_TEMPLATE. The protected LSP can be recognized because it will include the FAST_REROUTE object or have the "local protection desired" flag set in the SESSION_ATTRIBUTE object, or both.
LSRは1バックアップLSPsとことによると保護されたLSPにおいて複数のPathメッセージを受け取るかもしれません。 それぞれに関するこれらのPathメッセージには、異なったSENDER_TEMPLATEがあるでしょう。 それでFAST_REROUTE物を含んでいるか、またはSESSION_ATTRIBUTE物、または両方に「地方の保護必要な」旗を設定するので、保護された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メッセージを合併するための[RSVP-TE]の仕様に、そのLSRから出口までのEROが同じであるPathメッセージしか合併できません。 合併が起こるか、そして、メッセージが合併したPathの1つは保護されたLSPのためのものでした、そして、送られるべき最終的なPathメッセージが保護されたLSPのものであるに違いありません。 これはそのLSRの保護されたLSPにバックアップLSPsを合併します。 最終的な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
合併が起こって、すべてのPathメッセージがバックアップLSPsのためのものであり、次に、もしあればDETOUR物がセクション8.1で指定されるように変更されるなら
7.1.2. Merging Detours using the Path-Specific Method
7.1.2. 経路特有の方法を使用することで回り道を合併します。
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メッセージを受け取るかもしれません。 この場合、Path州の合併はREQUIREDです。 合併している規則は以下の通りです:
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もDETOUR物もないか、またはMPがLSPの出口であるなら、合併は必要ではありません。 [RSVP-TE]に従って、メッセージは処理されます。
Pan, et al. Standards Track [Page 29] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[29ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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状態と入って来るインタフェースを記録しなければなりません。 Pathメッセージが外向的なインタフェースと次のホップLSRを共有しないなら、MPは、それらが独立しているLSPsであると考えなければならなくて、彼らを合併してはいけません。
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を共有するすべてのPathメッセージに関しては、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.
1. Pathメッセージの1つ以上が保護されたLSPのためのもの(保護されたLSPはこのノードも、FAST_REROUTE物も、またはDETOUR物なしで溯源されたものである)であるなら、これらの1つは選ばれたPathメッセージにならなければなりません。 1つ以上があるかもしれません。 その場合、どれを進めたらよいかは、ローカルの決定です。 やめてください。
2. From the remaining set of Detour Path messages, eliminate from
consideration those that traverse nodes that others want to
avoid.
2. 残っているセットのDetour Pathメッセージから、考慮から他のものが避けたがっているノードを横断するものを排除してください。
3. If several still remain, which one to forward is a local
decision. If none remain, then the MP MAY try to find a new
route that avoids all nodes that merging Detour Paths want to
avoid; it will forward a Path message with that ERO.
3. 数個がまだ残っているなら、どれを進めたらよいかは、ローカルの決定です。 なにも残っていないなら、MPはすべてのノードを避ける新しいルートにDetour Pathsが避けたがっているその合併を見つけようとするかもしれません。 それはその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は、川下で定期的にそれをリフレッシュし始めなければなりません。 他のLSPsはこのノードで合併されていると考えられます。 出発しているリンクの帯域幅の予約において、帯域幅が予約されている前にどんな合併も起こったと考えられるべきです。 したがって、Fixed Filterスタイルは指定されますが、複数の回り道、そして/または、それらの保護されたLSP(外向的なインタフェースと次のホップLSRを共有するため合併されることになっている)はその外向的なインタフェースにおける最終的な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 SHOULDは最も最近受信された回り道Pathメッセージに対応してPathErrを送ります。 保護されたPathを選ぶなら、進めて、いくつかの回り道が避けたがっているノードを横断します、PathErrs SHOULDということになるように、合併できないそれらの回り道Pathsに対応して、送ってください。
Pan, et al. Standards Track [Page 30] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[30ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
7.1.2.1. An Example of Path Message Merging
7.1.2.1. 経路メッセージ合併に関する例
R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6
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->、R9、-、>R4->、R5、-、>R6] R3の回り道: [R3、-、>R8->、R9、-、>R5->、R6]
Example 4. Path Message Merging
例4。 経路メッセージ合併
In Example 4, R8 will receive Path messages that have the same SESSION and SENDER_TEMPLATE from detours for R2 and R3. During merging at R8, because detour R3 has a shorter ERO path length (that is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as the final LSP and will only propagate its Path messages downstream. Upon receiving a Resv (or a ResvTear) message, R8 must relay the messages toward both R2 and R3.
Example4では、R8はR2とR3のために回り道から同じSESSIONとSENDER_TEMPLATEを持っているPathメッセージを受け取るでしょう。 回り道R3には、より短いERO経路の長さがあるのでR8で合併する、(すなわち、EROがそうである、[R9、-、>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で終わります。
7.1.3. Message Handling for Merged Detours
7.1.3. 合併している回り道のためのメッセージハンドリング
When an LSR receives a ResvTear for an LSP, the LSR must determine whether it has an alternate associated LSP. For instance, if the ResvTear was received for a protected LSP but an associated backup LSP has not received a ResvTear, then the LSR has an alternate associated LSP. If the LSR does not have an alternate associated LSP, then the MP MUST propagate the ResvTear toward the LSP's ingress, and, for each backup LSP merged into that LSP at this LSR, the ResvTear SHOULD also be propagated along the backup LSP.
LSRがLSPのためにResvTearを受けるとき、LSRは、それが交互の関連LSPを持っているかどうか決定しなければなりません。 例えば、保護されたLSPのためにResvTearを受け取りましたが、関連バックアップLSPがResvTearを受けていないなら、LSRには、交互の関連LSPがあります。 LSRに交互の関連LSPがないなら、MPはLSPのイングレス、およびそれぞれのバックアップLSPがこのLSRにそのLSPに溶け込んだときのResvTear SHOULDに向かってResvTearを伝播しなければなりません、また、バックアップLSPに沿って伝播されてください。
The MP may receive PathTear messages for some of the merging LSPs. PathTear messages SHOULD NOT be propagated downstream until the MP has received PathTear messages for each of the merged LSPs. However, the fact that one or more of the merged LSPs has been torn down should be reflected in the downstream message, such as by changing the DETOUR object, if there is one.
MPはいくつかの合併しているLSPsへのPathTearメッセージを受け取るかもしれません。 PathTearはSHOULD NOTを通信させます。MPがそれぞれの合併しているLSPsへのPathTearメッセージを受け取るまで、川下に伝播されてください。 しかしながら、合併しているLSPsの1つ以上を取りこわしたという事実は川下のメッセージに反映されるべきです、DETOUR物を変えるのなどように、1つがあれば。
7.2. Handling Failures
7.2. 取り扱い失敗
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
川下のLSRが失敗したリンクの上に発送されたどんな保護されたLSPsのためにも地方のリンクの故障を検出すると、PathとResv状態をきれいにしてはいけません、そして、すぐに、PathTearとResvErrメッセージを送ってはいけません。 これがそうでないなら、施設バックアップ方法は利かないでしょう。 その上、川下のLSR SHOULDはリセットしました。
Pan, et al. Standards Track [Page 31] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[31ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
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.
まるで彼らがちょうどリフレッシュされたかのようにこれらのLSPsのためにタイマをリフレッシュしてください。 これは、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は失敗した保護されたLSPsに関連しているバックアップLSPsのためにまだメッセージをResvに送らなければなりません。 迂回トンネルを通してバックアップLSPを送ったなら、Pathメッセージの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は彼らのバックアップに失敗した既存の保護されたLSPsへのPathメッセージを受け入れるかもしれません。
8. Behavior of All LSRs
8. すべてのLSRsの動き
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.
本書では定義された目的と方法は交通で設計されたネットワークにおけるすべてのLSRsから振舞いを必要とします、保護された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の経路メッセージに含まれているなら、交通で設計されたネットワークにおけるLSRsは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番目に、交通の設計されたネットワークにおけるLSRsがセクション8.1における指定されるとしての回り道を合併できるのが経路特有の方法が-1つへの1つのバックアップ方法のために支持されることであるなら、必要です。
It is possible to avoid specific LSRs that do not support this behavior by assigning a link attribute to all the links of those LSPs and then requesting that backup paths exclude this link attribute.
それらのLSPsのすべてのリンクにリンク属性を割り当てて、次に、バックアップ道がこのリンク属性を除くよう要求することによってこの振舞いを支持しない特定のLSRsを避けるのは可能です。
8.1. Merging Detours in the Path-Specific Method
8.1. 経路特有の方法で回り道を合併します。
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.
同じSESSION、SENDER_TEMPLATE、外向的なインタフェース、および次のホップLSRと共に異なった回り道のための複数のPath Messagesを受け取るなら、LSRはDetour Merge Pointとして機能して、回り道Path Messagesを合併しなければなりません。 この合併はセクション7.1.2で指定されて、Example4に示されるように起こるべきです。
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:
さらに、行われた合併を反映するためにDETOUR物をアップデートするのが必要です。 これは最終的なLSPのために出発しているDETOUR物をフォーマットするのに以下のアルゴリズムを使用し終わっています:
Pan, et al. Standards Track [Page 32] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[32ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
- 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.
- すべての合併しているLSPsのすべてのDETOUR物からのすべての(PLR_Avoid_Node_ID(ID))組を新しい物に合併してください。 注文はわずかです。
9. Security Considerations
9. セキュリティ問題
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メッセージが互いから受信されたのを必要とすることに注意してください。
10. IANA Considerations
10. IANA問題
IANA [RFC-IANA] has assigned the following RSVP Class Numbers for objects defined in this document.
IANA[RFC-IANA]は本書では定義された物のために以下のRSVP Class民数記を割り当てました。
10.1. DETOUR Object
10.1. 回り道物
IANA has assigned:
IANAは割り当てました:
63 DETOUR
63回り道
Class Types or C-Types:
クラスタイプかC-タイプ:
7 IPv4
8 IPv6
7 IPv4 8 IPv6
Future C-Types will be assigned using the following guidelines:
将来のC-タイプは以下のガイドラインを使用することで選任されるでしょう:
C-Types 0 through 127 are assigned by Standards Action.
C-タイプの0〜127はStandards Actionによって割り当てられます。
C-Types 128 through 191 are assigned by Expert Review.
C-タイプの128〜191はExpert Reviewによって割り当てられます。
C-Types 192 through 255 are reserved for Vendor Private Use.
C-タイプの192〜255はVendor兵士のUseのために予約されます。
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.
範囲のC-タイプにおいて、192〜255に、C-タイプの後のDETOUR物の最初の4つの八重奏がネットワークバイトオーダーでVendorのSMI Network Management兵士のエンタープライズCodeであるに違いありません([ENT]を見ます)。
Pan, et al. Standards Track [Page 33] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[33ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
10.2. FAST_REROUTE Object
10.2. 速い_は物を別ルートで送ります。
IANA has assigned:
IANAは割り当てました:
205 FAST_REROUTE
205 速い_はコースを変更します。
Class Types or C-Types:
クラスタイプかC-タイプ:
1 FAST_REROUTE Type 1
7 RESERVED
1 速い_は1 7が予約したタイプを別ルートで送ります。
In the FAST_REROUTE object, C-Type 7 is reserved as it is still used by pre-standard implementations. Future C-Types will be assigned using the following guidelines:
FAST_REROUTE物では、それがプレ標準の実現でまだ使用されているとき、C-タイプ7は予約されています。 将来のC-タイプは以下のガイドラインを使用することで選任されるでしょう:
C-Types 0 through 127 are assigned by Standards Action.
C-タイプの0〜127はStandards Actionによって割り当てられます。
C-Types 128 through 191 are assigned by Expert Review.
C-タイプの128〜191はExpert Reviewによって割り当てられます。
C-Types 192 through 255 are reserved for Vendor Private Use.
C-タイプの192〜255はVendor兵士のUseのために予約されます。
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.
範囲のC-タイプにおいて、192〜255に、C-タイプの後のFAST_REROUTE物の最初の4つの八重奏がネットワークバイトオーダーでVendorのSMI Network Management兵士のエンタープライズCodeであるに違いありません([ENT]を見ます)。
Pan, et al. Standards Track [Page 34] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[34ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
11. Contributors
11. 貢献者
This document was written by George Swallow, Ping Pan, Alia Atlas, Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
このドキュメントはジョージSwallow、Ping Pan、アリアAtlas、ジーンフィリップVasseur、マーカスJork、Der-Hwaガン、およびデーヴ・クーパーによって書かれました。
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
ビーバーブルック道路Boxborough、ジーンフィリップVasseurシスコシステムズInc.300MA01719米国
Phone: +1 978 497 6238 EMail: jpv@cisco.com
以下に電話をしてください。 +1 6238年の978 497メール: jpv@cisco.com
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803 USA
マーカスJorkはMA01803米国の技術8ニューイングランドの幹部社員公園バーリントンを採石します。
Phone: +1 781 359 5071 EMail: mjork@quarrytech.com
以下に電話をしてください。 +1 5071年の781 359メール: mjork@quarrytech.com
Der-Hwa Gan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
Der-Hwaガン杜松は1194N.マチルダ・Aveカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
Phone: +1 408 745 2074 EMail: dhg@juniper.net
以下に電話をしてください。 +1 2074年の408 745メール: dhg@juniper.net
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 USA
デーヴ・桶屋グローバルクロッシング960ハムリン法廷カリフォルニア94089サニーベル(米国)
Phone: +1 916 415 0437 EMail: dcooper@gblx.net
以下に電話をしてください。 +1 0437年の916 415メール: dcooper@gblx.net
Pan, et al. Standards Track [Page 35] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[35ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
12. Acknowledgments
12. 承認
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、トニー・李、ヤコフRekhter、およびカーティスVillamizarから入力と役に立つコメントを承諾したいと思います。 人に感謝します、そして、私たちは非常に貴重な考えと提案を特に、提供しました。(その人は、相互運用性テストと分野道にかかわりました)。 それらは、ロブGoguenと、キャロル・イトゥラルデと、Safaaハサンの、そして、リチャードSouthernのブルック・べイリーと、Bijan Jabbariです。
13. Normative References
13. 引用規格
[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の機能的な仕様」、RFC2205、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-ワーズ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
[ENT]IANA私企業番号、 http://www.iana.org/assignments/enterprise-numbers
Pan, et al. Standards Track [Page 36] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[36ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
Authors' Addresses
作者のアドレス
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
ビーバーブルック道路Boxborough、ジョージツバメシスコシステムズInc.300MA01719米国
Phone: +1 978 244 8143 EMail: swallow@cisco.com
以下に電話をしてください。 +1 8143年の978 244メール: swallow@cisco.com
Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 USA
なべハンマーの頭システム640クライド法廷カリフォルニア94043マウンテンビュー(米国)を確認してください。
EMail: ppan@hammerheadsystems.com
メール: ppan@hammerheadsystems.com
Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA
アリア地図帳Aviciシステム101ビルリカアベニューN.MA01862ビルリカ(米国)
Phone: +1 978 964 2070 EMail: aatlas@avici.com
以下に電話をしてください。 +1 2070年の978 964メール: aatlas@avici.com
Pan, et al. Standards Track [Page 37] RFC 4090 RSVP-TE Fast Reroute May 2005
なべ、他 標準化過程[37ページ]RFC4090RSVP-Teは、5月が2005であると速く別ルートで送ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Pan, et al. Standards Track [Page 38]
なべ、他 標準化過程[38ページ]
一覧
スポンサーリンク
