RFC4426 日本語訳
4426 Generalized Multi-Protocol Label Switching (GMPLS) RecoveryFunctional Specification. J. Lang, Ed., B. Rajagopalan, Ed., D.Papadimitriou, Ed.. March 2006. (Format: TXT=55820 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lang, Ed.
Request for Comments: 4426 B. Rajagopalan, Ed.
Category: Standards Track D. Papadimitriou, Ed.
March 2006
ワーキンググループのJ.ラング、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド4426B.Rajagopalan、カテゴリ: エド標準化過程D.Papadimitriou、2006年3月
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification
一般化されたマルチプロトコルラベルスイッチング(GMPLS)の回復の機能的な仕様
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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents.
このドキュメントはGeneralized Multi-プロトコルのLabel Switchingの(GMPLS)ベースの回復を支持するのに必要であるプロトコル拡大(すなわち、保護と回復)の機能的な記述を提示します。 特定の形式について議定書の中で述べてください。そうすれば、メカニズムは仲間ドキュメントで説明されるでしょう。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 3
2. Span Protection .............................................. 3
2.1. Unidirectional 1+1 Dedicated Protection ................ 4
2.2. Bi-directional 1+1 Dedicated Protection ................ 5
2.3. Dedicated 1:1 Protection with Extra Traffic ............ 6
2.4. Shared M:N Protection .................................. 8
2.5. Messages ............................................... 10
2.5.1. Failure Indication Message ..................... 10
2.5.2. Switchover Request Message ..................... 11
2.5.3. Switchover Response Message .................... 11
2.6. Preventing Unintended Connections ...................... 12
3. End-to-End (Path) Protection and Restoration ................. 12
3.1. Unidirectional 1+1 Protection .......................... 12
3.2. Bi-directional 1+1 Protection .......................... 12
3.2.1. Identifiers .................................... 13
3.2.2. Nodal Information .............................. 14
1. 序論… 2 1.1. このドキュメントで中古のコンベンション… 3 2. 保護にかかってください… 3 2.1. 単方向1の+1ひたむきな保護… 4 2.2. 1つの双方向の+1ひたむきな保護… 5 2.3. 余分な交通との1:1保護を捧げます… 6 2.4. M: N保護を共有します… 8 2.5. メッセージ… 10 2.5.1. 失敗指示メッセージ… 10 2.5.2. 転換要求メッセージ… 11 2.5.3. 転換応答メッセージ… 11 2.6. 故意でないコネクションズを防ぎます… 12 3. 終わりから終わりへの(経路)保護と王政復古… 12 3.1. 単方向の1+1保護… 12 3.2. 双方向の1+1保護… 12 3.2.1. 識別子… 13 3.2.2. こぶのような情報… 14
Lang, et al. Standards Track [Page 1] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[1ページ]RFC4426GMPLS回復
3.2.3. End-to-End Failure Indication Message .......... 14
3.2.4. End-to-End Failure Acknowledgement Message ..... 15
3.2.5. End-to-End Switchover Request Message .......... 15
3.2.6. End-to-End Switchover Response Message ......... 15
3.3. Shared Mesh Restoration ................................ 15
3.3.1. End-to-End Failure Indication and
Acknowledgement Message ........................ 16
3.3.2. End-to-End Switchover Request Message .......... 16
3.3.3. End-to-End Switchover Response Message ......... 17
4. Reversion and Other Administrative Procedures ................ 17
5. Discussion ................................................... 18
5.1. LSP Priorities During Protection ....................... 18
6. Security Considerations ...................................... 19
7. Contributors ................................................. 20
8. References ................................................... 21
8.1. Normative References ................................... 21
8.2. Informative References ................................. 22
3.2.3. 終わりから終わりへの失敗指示メッセージ… 14 3.2.4. 終わりから終わりへの失敗確認メッセージ… 15 3.2.5. 終わりから終わりへの転換要求メッセージ… 15 3.2.6. 終わりから終わりへの転換応答メッセージ… 15 3.3. メッシュ王政復古を共有します… 15 3.3.1. 終わりから終わりへの失敗指示と確認メッセージ… 16 3.3.2. 終わりから終わりへの転換要求メッセージ… 16 3.3.3. 終わりから終わりへの転換応答メッセージ… 17 4. 逆戻りと他の行政手続… 17 5. 議論… 18 5.1. 保護の間のLSPプライオリティ… 18 6. セキュリティ問題… 19 7. 貢献者… 20 8. 参照… 21 8.1. 標準の参照… 21 8.2. 有益な参照… 22
1. Introduction
1. 序論
A requirement for the development of a common control plane for both optical and electronic switching equipment is that there must be signaling, routing, and link management mechanisms that support data plane fault recovery. In this document, the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are used only when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery period (see [RFC4427]).
光学の、そして、電子の両方のスイッチ装置のための共通制御機構飛行機の開発のための要件はシグナリング、ルーティング、およびデータ飛行機欠点回復を支持するリンク管理メカニズムがあるに違いないということです。 本書では、「回復」という用語は保護と回復の両方を指示するのに一般的に使用されます。 分化が必要であるときにだけ、種の用語「保護」と「回復」は使用されています。 回復の期間、行われた資源配分に基づいて保護と回復の微細な区別をします([RFC4427]を見てください)。
A label-switched path (LSP) may be subject to local (span), segment, and/or end-to-end recovery. Local span protection refers to the protection of the link (and hence all the LSPs marked as required for span protection and routed over the link) between two neighboring switches. Segment protection refers to the recovery of an LSP segment (i.e., an SNC in the ITU-T terminology) between two nodes, i.e., the boundary nodes of the segment. End-to-end protection refers to the protection of an entire LSP from the ingress to the egress port. The end-to-end recovery models discussed in this document apply to segment protection where the source and destination refer to the protected segment rather than the entire LSP. Multiple recovery levels may be used concurrently by a single LSP for added resiliency; however, the interaction between levels affects any one direction of the LSP results in both directions of the LSP being switched to a new span, segment, or end-to-end path.
ラベルで切り換えられた経路(LSP)は終わりから地方の(長さ)、セグメント、そして/または、終わりへの回復を被りやすいかもしれません。 地方の長さ保護は2個の隣接しているスイッチの間のリンク(したがって、すべてのLSPsが必要に応じて長さ保護に注目して、リンクの上に掘った)の保護について言及します。 セグメント保護は2つのノード(すなわち、セグメントの境界ノード)の間のLSPセグメント(すなわち、ITU-T用語のSNC)の回復について言及します。 終わりから終わりへの保護は全体のLSPのイングレスから出口港までの保護について言及します。 情報筋と目的地が全体のLSPよりむしろ保護されたセグメントについて言及するところで終わりから終わりへの回復本書では議論したモデルはセグメント保護に適用します。 複数の回復レベルが加えられた弾性に同時に独身のLSPによって使用されるかもしれません。 しかしながら、レベルの間の相互作用は終わりから新しい長さ、セグメント、または端への経路に切り換えられるLSPの両方の方向にLSP結果のどんな指示にも影響します。
Lang, et al. Standards Track [Page 2] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[2ページ]RFC4426GMPLS回復
Unless otherwise stated, all references to "link" in this document indicate a bi-directional link (which may be realized as a pair of unidirectional links).
別の方法で述べられない場合、「リンクする」すべての参照が本書では、双方向のリンク(1組の単方向がリンクされるとき、実感されるかもしれない)を示します。
Consider the control plane message flow during the establishment of an LSP. This message flow proceeds from an initiating (or source) node to a terminating (or destination) node, via a sequence of intermediate nodes. A node along the LSP is said to be "upstream" from another node if the former occurs first in the sequence. The latter node is said to be "downstream" from the former node. That is, an "upstream" node is closer to the initiating node than a node further "downstream". Unless otherwise stated, all references to "upstream" and "downstream" are in terms of the control plane message flow.
LSPの設立の間、コントロール飛行機メッセージが流れであると考えてください。 このメッセージ流動は開始(または、ソース)ノードから終わり(または、目的地)ノードまで続きます、中間的ノードの系列で。 前者が最初に系列で起こるなら、LSPに沿ったノードは別のノードから「上流である」と言われます。 後者のノードは前のノードから「川下である」と言われています。 すなわち、「上流」のノードが「川下に」開始ノードのノードより近くにさらにあります。 別の方法で述べられない場合、コントロール飛行機メッセージ流動に関して「上流」と「川下」のすべての参照があります。
The flow of the data traffic is defined from ingress (source node) to egress (destination node). Note that for bi-directional LSPs, there are two different data plane flows, one for each direction of the LSP. This document presents a protocol functional description to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol-specific formats, encoding, and mechanisms will be described in companion documents.
データ通信量の流れはイングレス(ソースノード)から出口(目的地ノード)まで定義されます。 双方向のLSPsを支持して、2回の異なったデータ飛行機流れ、LSPの各指示あたり1つがいることに注意してください。 このドキュメントは、Generalized Multi-プロトコルのLabel Switchingの(GMPLS)ベースの回復(すなわち、保護と回復)を支持するためにプロトコルの機能的な記述を提示します。 プロトコル特有の形式、コード化、およびメカニズムは仲間ドキュメントで説明されるでしょう。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In addition, the reader is assumed to be familiar with the terminology used in [RFC3945], [RFC3471] and referenced as well as [RFC4427].
さらに、読者が[RFC3945]、[RFC3471]で使用されて、[RFC4427]と同様に参照をつけられる用語によく知られさせると思われます。
2. Span Protection
2. 長さ保護
Consider a (working) link i between two nodes A and B. There are two fundamental models for span protection. The first is referred to as 1+1 protection. Under this model, a dedicated link j is pre-assigned to protect link i. LSP traffic is permanently bridged onto both links i and j at the ingress node, and the egress node selects the signal (i.e., normal traffic) from i or j, based on a selection function (e.g., signal quality). Under unidirectional 1+1 span protection (Section 2.1), each node A and B acts autonomously to select the signal from the working link i or the protection link j. Under bi-directional 1+1 span protection (Section 2.2) the two nodes A and B coordinate the selection function such that they select the signal from the same link, i or j.
2つのノードAとB.の間で(働いていること)のリンクがiであると考えてください。Thereは長さ保護のための2つの基本的なモデルです。 1番目は1+1保護と呼ばれます。 このモデルの下では、専用リンクjは、リンクiを保護するためにあらかじめ割り当てられます。 LSP交通は永久にイングレスノードのリンクiとjの両方に橋を架けられます、そして、出口ノードはiかjからの信号(すなわち、通常の交通)を選択します、選択機能(例えば、信号品質)に基づいて。 各(セクション2.1)、ノードA、およびBが働くリンクからの信号を選択するために自主的に機能させる単方向の1+1長さ保護で、私か保護がjをリンクします。 双方向の1+1長さ保護(セクション2.2)で、2つのノードAとBが選択機能を調整するので、彼らは同じリンク、iまたはjからの信号を選択します。
Lang, et al. Standards Track [Page 3] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[3ページ]RFC4426GMPLS回復
Under the second model, a set of N working links are protected by a set of M protection links, usually with M =< N. A failure in any of the N working links results in traffic being switched to one of the M protection links that is available. This is typically a three-step process: first the data plane failure is detected at the egress node and reported (notification), then a protection link is selected, and finally, the LSPs on the failed link are moved to the protection link. If reversion is supported, a fourth step is included, i.e., return of the traffic to the working link (when the working link has recovered from the failure). In Section 2.3, 1:1 span protection is described. In Section 2.4, M:N span protection is described, where M =< N.
第2代モデルの下では、1セットのN働くリンクはM通常、Mとの保護リンク=<N.の1セットによって保護されます。N働くリンクのどれかでのA失敗は保護がリンクするMの利用可能な1つに切り換えられる交通をもたらします。 通常、これは3ステップの過程です: まず最初に、データ飛行機の故障は、出口ノードに検出されて、報告されます、そして、(通知)次に、保護リンクは選択されます、そして、最終的に、失敗したリンクの上のLSPsは保護リンクに動かされます。 逆戻りが支持されるなら、第4のステップは含まれています、すなわち、働くリンクへの交通の復帰(働くリンクが失敗から回収されたとき)。 セクション2.3では、1:1長さ保護は説明されます。 セクション2.4、Mで: Mが<Nと等しいところでN長さ保護は説明されます。
2.1. Unidirectional 1+1 Dedicated Protection
2.1. 単方向1の+1ひたむきな保護
Suppose a bi-directional LSP is routed over link i between two nodes A and B. Under unidirectional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i. LSP traffic is permanently bridged on both links at the ingress node, and the egress node selects the normal traffic from one of the links, i or j. If a node (A or B) detects a failure of a span, it autonomously invokes a process to receive the traffic from the protection span. Thus, it is possible that node A selects the signal from link i in the B to A direction of the LSP, and node B selects the signal from link j in the A to B direction.
双方向のLSPが2つのノードAとB.Under単方向の1+1保護とのリンクiの上に発送されるなら、専用リンクjは働くリンクを保護するためにあらかじめ割り当てられた私です。 LSP交通は永久にイングレスノードの両方のリンクの上に橋を架けられます、そして、出口ノードはリンク、iまたはjの1つからの通常の交通を選択します。 ノードであるなら、(AかB)は長さの失敗を検出して、それは、保護の長さからの交通を受けるために自主的に過程を呼び出します。 したがって、ノードAがBでリンクiからの信号をLSPのA方向に選択するのが、可能であり、ノードBはAでリンクjからの信号をB方向に選択します。
The following functionality is required for 1+1 unidirectional span protection:
以下の機能性が1+1単方向の長さ保護に必要です:
o Routing: A single TE link encompassing both working and
protection links SHOULD be announced with a Link Protection
Type "Dedicated 1+1", along with the bandwidth parameters for
the working link. As the resources are consumed/released, the
bandwidth parameters of the TE link are adjusted accordingly.
Encoding of the Link Protection Type and bandwidth parameters
in IS-IS is specified in [RFC4205]. Encoding of this
information in OSPF is specified in [RFC4203].
o ルート設定: 独身のTEはリンクします。Link Protection Typeが発表される状態で「+1に1を捧げた」ということになってください働きと保護リンクSHOULDの両方を取り囲んで、働くリンクのための帯域幅パラメタと共に。 リソースが消費されるか、または発表されるとき、TEリンクの帯域幅パラメタはそれに従って、調整されます。 中のLink Protection Typeと帯域幅パラメタのコード化、-、[RFC4205]では、指定されます。 OSPFでのこの情報のコード化は[RFC4203]で指定されます。
o Signaling: The Link Protection object/TLV SHOULD be used to
request "Dedicated 1+1" link protection for that LSP. This
object/TLV is defined in [RFC3471]. If the Link Protection
object/TLV is not used, link selection is a matter of local
policy. No additional signaling is required when a fail-over
occurs.
o シグナリング: Link Protection物/TLV SHOULD、そのLSPに要求が「+1に1を捧げた」というリンク保護に使用されてください。 この物/TLVは[RFC3471]で定義されます。 Link Protection物/TLVが使用されていないなら、リンク選択はローカルの方針の問題です。 フェイルオーバーが起こるとき、どんな追加シグナリングも必要ではありません。
Lang, et al. Standards Track [Page 4] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[4ページ]RFC4426GMPLS回復
o Link management: Both nodes MUST have a consistent view of the
link protection association for the spans. This can be done
using the Link Management Protocol (LMP) [RFC4204], or if LMP
is not used, this MUST be configured manually.
o 管理をリンクしてください: 両方のノードには、長さへのリンク保護協会の一貫した視点がなければなりません。 これがLink Managementプロトコル(LMP)[RFC4204]を使用し終わることができますか、またはLMPが使用されていないなら、手動でこれを構成しなければなりません。
2.2. Bi-directional 1+1 Dedicated Protection
2.2. 1つの双方向の+1ひたむきな保護
Suppose a bi-directional LSP is routed over link i between two nodes A and B. Under bi-directional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i. LSP traffic is permanently duplicated on both links, and under normal conditions, the traffic from link i is received by nodes A and B (in the appropriate directions). A failure affecting link i results in both A and B switching to the traffic on link j in the respective directions. Note that some form of signaling is required to ensure that both A and B start receiving traffic from the protection link.
双方向のLSPが2つのノードAとB.のUnderの双方向の1+1保護とのリンクiの上に発送されるなら、専用リンクjは働くリンクを保護するためにあらかじめ割り当てられた私です。 永久に両方のリンクの上にLSP交通をコピーします、そして、正常な状況では、ノードAとB(適切な方向への)はリンクiからの交通を受けます。 リンクiに影響する失敗は、それぞれの指示に基づきリンクjにおける交通に切り替わりながら、AとBの両方をもたらします。 何らかのフォームのシグナリングがAとBの両方が保護リンクからの交通を受け始めるのを保証するのに必要であることに注意してください。
The basic steps in 1+1 bi-directional span protection are as follows:
1つの+1双方向の長さ保護における基本的なステップは以下の通りです:
1. If a node (A or B) detects the failure of the working link (or
a degradation of signal quality over the working link), it
SHOULD begin receiving on the protection link and send a
Switchover Request message reliably to the other node (B or A,
respectively). This message SHOULD indicate the identity of
the failed working link and provide other relevant information.
1. (AかB)はノードであるなら働くリンク(または、働くリンクの上の信号品質の低下)の失敗を検出します、それ。SHOULDは他のノード(それぞれBかA)に保護リンクの上に受信し始めて、Switchover Requestメッセージを確かに送ります。 このメッセージSHOULDは失敗した働くリンクのアイデンティティを示して、他の関連情報を提供します。
2. Upon receipt of the Switchover Request message, a node MUST
begin receiving from the protection link and send a Switchover
Response message to the other node (A or B, respectively).
Because both the working/protect spans are exposed to routing
and signaling as a single link, the switchover SHOULD be
transparent to routing and signaling.
2. Switchover Requestメッセージを受け取り次第、ノードは、もう片方のノード(それぞれAかB)に保護リンクから受信し始めて、Switchover Responseメッセージを送らなければなりません。 両方の働く/が保護されるので長さは、単一のリンクとしてルーティングに露出して、合図しました、転換SHOULDがルーティングに透明で合図していて。
The following functionality is required for 1+1 bi-directional span protection:
以下の機能性が1つの+1双方向の長さ保護に必要です:
o The routing procedures are the same as in 1+1 unidirectional.
o ルーティング手順は1+1単方向と同じです。
o The signaling procedures are the same as in 1+1 unidirectional.
o シグナリング手順は1+1単方向と同じです。
o In addition to the procedures described in 1+1
(unidirectional), a Switchover Request message MUST be used to
signal the Switchover Request. This can be done using LMP
[RFC4204]. Note that GMPLS-based mechanisms MAY not be
necessary when the underlying span (transport) technology
provides such a mechanism.
o 1+1(単方向)のときに説明された手順に加えて、Switchover Requestに合図するのにSwitchover Requestメッセージを使用しなければなりません。 これはLMP[RFC4204]を使用し終わることができます。 基本的な長さ(輸送)技術がそのようなメカニズムを提供するとき、GMPLSベースのメカニズムは必要でないかもしれないことに注意してください。
Lang, et al. Standards Track [Page 5] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[5ページ]RFC4426GMPLS回復
2.3. Dedicated 1:1 Protection with Extra Traffic
2.3. 余分な交通とのひたむきな1:1保護
Consider two adjacent nodes, A and B. Under 1:1 protection, a dedicated link j between A and B is pre-assigned to protect working link i. Link j may be carrying (pre-emptable) Extra Traffic. A failure affecting link i results in the corresponding LSP(s) being restored to link j. Extra Traffic being routed over link j may need to be pre-empted to accommodate the LSPs that have to be restored.
2隣接しているノード、A、およびB.を考えてください。Under1:1保護、専用リンクjはAとBとの間に働くリンクを保護するためにあらかじめ割り当てられた私です。 リンクjは携帯(プレ空に可能)の余分なTrafficであるかもしれません。 リンクiに影響する失敗はjをリンクするために返される対応するLSP(s)をもたらします。 リンクjの上に発送される余分なTrafficは、返されなければならないLSPsを収容するために先取りされる必要があるかもしれません。
Once a fault is isolated/localized, the affected LSP(s) must be moved to the protection link. The process of moving an LSP from a failed (working) link to a protection link must be initiated by one of the nodes, A or B. This node is referred to as the "master". The other node is called the "slave". The determination of the master and the slave may be based on configured information or protocol specific requirements.
欠点がいったん隔離されるか、または局所化されると、影響を受けるLSP(s)を保護リンクに動かさなければなりません。 ノードの1つで保護リンクへの失敗した(働いていること)のリンクからLSPを動かす過程に着手しなければならなくて、AかB.Thisノードが「マスター」と呼ばれます。 もう片方のノードは「奴隷」と呼ばれます。 マスターと奴隷の決断は、構成された情報に基づいているか、または決められた一定の要求について議定書の中で述べるかもしれません。
The basic steps in dedicated 1:1 span protection (ignoring reversion) are as follows:
ひたむきな1:1長さ保護(逆戻りを無視する)における基本的なステップは以下の通りです:
1. If the master detects/localizes a link failure event, it
invokes a process to allocate the protection link to the
affected LSP(s).
1. マスターがリンク失敗出来事を検出するか、または局部にとどめるなら、それは、影響を受けるLSP(s)への保護リンクを割り当てるために過程を呼び出します。
2. If the slave detects a link failure event, it informs the
master of the failure using a failure indication message. The
master then invokes the same procedure as (1) to move the LSPs
to the protection link. If the protection link is carrying
Extra Traffic, the slave stops using the span for the Extra
Traffic.
2. 奴隷がリンク失敗出来事を検出するなら、それは、失敗指示メッセージを使用することで失敗のマスターに知らせます。 そして、マスターは、LSPsを保護リンクに動かすために(1)と同じ手順を呼び出します。 保護リンクがExtra Trafficを運ぶなら、奴隷は、Extra Trafficに長さを使用するのを止めます。
3. Once the span protection procedure is invoked in the master, it
requests the slave to switch the affected LSP(s) to the
protection link. Prior to this, if the protection link is
carrying Extra Traffic, the master stops using the span for
this traffic (i.e., the traffic is dropped by the master and
not forwarded into or out of the protection link).
3. 長さ保護手順がマスターにいったん呼び出されると、それは、影響を受けるLSP(s)を保護リンクに切り換えるよう奴隷に要求します。 この前に、保護リンクがExtra Trafficを運ぶなら、マスターは、この交通に長さを使用するのを止めます(すなわち、交通は、マスターによって落とされて、リンクの中、または、保護リンクから進められません)。
4. The slave sends an acknowledgement to the master. Prior to
this, the slave stops using the link for Extra Traffic (i.e.,
the traffic is dropped by the slave and not forwarded into or
out of the protection link). It then starts sending the normal
traffic on the selected protection link.
4. 奴隷は承認をマスターに送ります。 この前に、奴隷は、Extra Trafficにリンクを使用するのを止めます(すなわち、交通は、奴隷によって落とされて、リンクの中、または、保護リンクから進められません)。 そして、それは通常の交通を選択された保護リンクを送り始めます。
5. When the master receives the acknowledgement, it starts sending
and receiving the normal traffic over the new link. The
switchover of the LSPs is thus completed.
5. マスターが承認を受けるとき、それは、新しいリンクの上に通常の交通を送って、受け始めます。 LSPsの転換はこのようにして終了しています。
Lang, et al. Standards Track [Page 6] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[6ページ]RFC4426GMPLS回復
Note: Although this mechanism implies more traffic dropped than
necessary, it is preferred over possible misconnections during the
recovery process.
以下に注意してください。 このメカニズムは、必要とするより交通が低下したのを含意しますが、可能な付け違いよりそれは回復の過程の間好まれます。
From the description above, it is clear that 1:1 span protection may require up to three signaling messages for each failed span: a failure indication message, an LSP Switchover Request message, and an LSP Switchover Response message. Furthermore, it may be possible to switch multiple LSPs from the working span to the protection span simultaneously.
記述によって、上では、1:1長さ保護がそれぞれの失敗した長さへの最大3つのシグナリングメッセージを必要とするのが、明確です: 失敗指示メッセージ、LSP Switchover Requestメッセージ、およびLSP Switchover Responseメッセージ。 その上、同時に働く長さから保護の長さに複数のLSPsを切り換えるのは可能であるかもしれません。
The following functionality is required for dedicated 1:1 span protection:
以下の機能性がひたむきな1:1長さ保護に必要です:
o Pre-emption MUST be supported to accommodate Extra Traffic.
o Extra Trafficを収容するために先取りを支持しなければなりません。
o Routing: A single TE link encompassing both working and
protection links is announced with a Link Protection Type
"Dedicated 1:1". If Extra Traffic is supported over the
protection link, then the bandwidth parameters for the
protection link MUST also be announced. The differentiation
between bandwidth for working and protect links is made using
priority mechanisms. In other words, the network MUST be
configured such that bandwidth at priority X or lower is
considered Extra Traffic.
o ルート設定: 働きと保護リンクの両方を取り囲むTEがリンクするシングルはLink Protection Typeが発表される状態で「1を: 何1インチも捧げた」ということです。 また、Extra Trafficが保護リンクの上に支持されるなら、保護リンクのための帯域幅パラメタを発表しなければなりません。 保護してください。リンクは、優先権メカニズムを使用することで作られています。そして、働くための帯域幅の間の分化、言い換えれば、ネットワークを構成しなければならないので、優先権Xか下側の帯域幅はExtra Trafficであると考えられます。
If there is a failure on the working link, then the normal
traffic is switched to the protection link, pre-empting Extra
Traffic if necessary. The bandwidth for the protection link
MUST be adjusted accordingly.
働くリンクの上に失敗があれば、通常の交通は保護リンクに切り換えられます、必要なら、Extra Trafficを先取りして。 それに従って、保護リンクへの帯域幅を調整しなければなりません。
o Signaling: To establish an LSP on the working link, the Link
Protection object/TLV indicating "Dedicated 1:1" SHOULD be
included in the signaling request message for that LSP. To
establish an LSP on the protection link, the appropriate
priority (indicating Extra Traffic) SHOULD be used for that
LSP. These objects/TLVs are defined in [RFC3471]. If the Link
Protection object/TLV is not used, link selection is a matter
of local policy.
o シグナリング: 働くリンク、Link Protection物/TLV表示のときにLSPを証明するために、「ひたむきな1: 1インチはそのLSPへのシグナリング要求メッセージに含まれるべきです」。 保護リンクの上のLSP、適切な優先権(Extra Trafficを示す)SHOULDを証明するには、そのLSPに使用されてください。 これらの物/TLVsは[RFC3471]で定義されます。 Link Protection物/TLVが使用されていないなら、リンク選択はローカルの方針の問題です。
o Link management: Both nodes MUST have a consistent view of the
link protection association for the spans. This can be done
using LMP [RFC4204] or via manual configuration.
o 管理をリンクしてください: 両方のノードには、長さへのリンク保護協会の一貫した視点がなければなりません。 これはLMP[RFC4204]を使用し終わっているか、手動の構成であることができます。
o When a link failure is detected at the slave, a failure
indication message MUST be sent to the master informing the
node of the link failure.
o 奴隷にリンクの故障を検出するとき、リンクの故障のノードを知らせるマスターに失敗指示メッセージを送らなければなりません。
Lang, et al. Standards Track [Page 7] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[7ページ]RFC4426GMPLS回復
2.4. Shared M:N Protection
2.4. 分配しているM: N保護
Shared M:N protection is described with respect to two neighboring nodes, A and B. The scenario considered is as follows:
A、共有されて、M: N保護は2つの隣接しているノードに関して説明されます、そして、シナリオが考えたB.は以下の通りです:
o At any point in time, there are two sets of links between A and
B, i.e., a working set of N (bi-directional) links carrying
traffic subject to protection and a protection set of M (bi-
directional) links. A protection link may be carrying Extra
Traffic. There is no a priori relationship between the two
sets of links, but the value of M and N MAY be pre-configured.
The specific links in the protection set MAY be pre-configured
to be physically diverse to avoid the possibility of failure
events affecting a large proportion of protection links (along
with working links).
o 時間内にの任意な点に、AとB(すなわち、保護を条件とした交通を運んで、保護が設定するM(2方向の)リンクのN(双方向)のリンクのワーキングセット)との2セットのリンクがあります。 保護リンクはExtra Trafficを運んでいるかもしれません。 2セットのリンクの間には、先験的な関係は全くありませんが、MとNの値はあらかじめ設定されるかもしれません。 保護セットにおける特定のリンクは、保護リンク(働くリンクに伴う)の大部分に影響する失敗出来事の可能性を避けるために物理的に多様になるようにあらかじめ設定されるかもしれません。
o When a link in the working set is affected by a failure, the
normal traffic is diverted to a link in the protection set, if
such a link is available. Note that such a link might be
carrying more than one LSP, e.g., an OC-192 link carrying four
STS-48 LSPs.
o ワーキングセットのリンクが失敗で影響を受けるとき、通常の交通は保護セットでリンクに紛らされます、そのようなリンクが利用可能であるなら。 そのようなリンクが1LSP、例えば4STS-48 LSPsを運ぶOC-192リンクを運んでいるかもしれないことに注意してください。
o More than one link in the working set may be affected by the
same failure event. In this case, there may not be an adequate
number of protection links to accommodate all of the affected
traffic carried by failed working links. The set of affected
working links that are actually restored over available
protection links is then subject to policies (e.g., based on
relative priority of working traffic). These policies are not
specified in this document.
o ワーキングセットの1個以上のリンクが同じ失敗出来事で影響を受けるかもしれません。 この場合、失敗した働くリンクによって運ばれた影響を受ける交通のすべてを収容する適切な数の保護リンクがないかもしれません。 実際に利用可能な保護リンクの上に返される影響を受ける働くリンクのセットはその時、方針(例えば、働く交通の相対的な優先権に基づいている)を受けることがあります。 これらの方針は本書では指定されません。
o When normal traffic must be diverted from a failed link in the
working set to a protection link, the decision as to which
protection link is chosen is always made by one of the nodes, A
or B. This node is considered the "master" and it is required
to both apply any policies and select specific protection links
to divert working traffic. The other node is considered the
"slave". The determination of the master and the slave MAY be
based on configured information, protocol-specific
requirements, or as a result of running a neighbor discovery
procedure.
o ワーキングセットの失敗したリンクから通常の交通を保護リンクに紛らさなければならないとき、いつもノードの1つで、保護リンクが選ばれている決定をします、そして、「マスター」であるとAかB.Thisノードを考えます、そして、どんな方針も適用して、働く交通を紛らすために特異的予防リンクを選択するためにそれを必要とします。 もう片方のノードは「奴隷」であると考えられます。 マスターと奴隷の決断は構成された情報、プロトコル特有の要件、または走行の結果、隣人発見手順に基づくかもしれません。
o Failure events are detected by transport layer mechanisms, if
available (e.g., SONET Alarm Indication Signal (AIS)/Remote
Defect Indication (RDI)). Since the bi-directional links are
formed by a pair of unidirectional links, a failure in the link
from A to B is typically detected by B, and a failure in the
opposite direction is detected by A. It is possible for a
o 失敗出来事は、トランスポート層メカニズムによって検出されていて、利用可能です(例えば、Sonet Alarm Indication Signal(AIS)/リモートなDefect Indication(RDI))。 双方向のリンクが1組の単方向のリンクによって形成されて、AからBへのリンクでの失敗がBによって通常検出されて、逆方向への失敗がA.によって検出されて、aに、Itが可能であるということであるので
Lang, et al. Standards Track [Page 8] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[8ページ]RFC4426GMPLS回復
failure to simultaneously affect both directions of the bi-
directional link. In this case, A and B will concurrently
detect failures, in the B-to-A direction and in the A-to-B
direction, respectively.
同時に両性愛者の方向のリンクの両方の指示に影響しないこと。 この場合、AとBは同時にそれぞれBからAへの方向とAからBへの方向に失敗を検出するでしょう。
The basic steps in M:N protection (ignoring reversion) are as follows:
M: N保護(逆戻りを無視する)における基本的なステップは以下の通りです:
1. If the master detects a failure of a working link, it
autonomously invokes a process to allocate a protection link to
the affected traffic.
1. マスターが働くリンクの失敗を検出するなら、それは、影響を受ける交通への保護リンクを割り当てるために自主的に過程を呼び出します。
2. If the slave detects a failure of a working link, it MUST
inform the master of the failure using a failure indication
message. The master then invokes the same procedure as above
to allocate a protection link. (It is possible that the master
has itself detected the same failure, for example, a failure
simultaneously affecting both directions of a link.)
2. 奴隷が働くリンクの失敗を検出するなら、失敗指示メッセージを使用して、それは失敗のマスターに知らせなければなりません。 そして、マスターは保護リンクを割り当てるためには上の同じ手順を呼び出します。 マスターがそれ自体を検出させるのは可能です。(同じ失敗、例えば、同時にリンクについて両方の指示に影響する失敗、)
3. Once the master has determined the identity of the protection
link, it indicates this to the slave and requests the
switchover of the traffic (using a "Switchover Request"
message). Prior to this, if the protection link is carrying
Extra Traffic, the master stops using the link for this traffic
(i.e., the traffic is dropped by the master and not forwarded
into or out of the protection link).
3. マスターがいったん保護リンクのアイデンティティを決定すると、それは、これを奴隷に示して、交通の転換を要求します(「転換要求」メッセージを使用して)。 この前に、保護リンクがExtra Trafficを運ぶなら、マスターは、この交通にリンクを使用するのを止めます(すなわち、交通は、マスターによって落とされて、リンクの中、または、保護リンクから進められません)。
4. The slave sends a "Switchover Response" message back to the
master. Prior to this, if the selected protection link is
carrying traffic that could be pre-empted, the slave stops
using the link for this traffic (i.e., the traffic is dropped
by the slave and not forwarded into or out of the protection
link). It then starts sending the normal traffic on the
selected protection link.
4. 奴隷は「転換応答」メッセージをマスターに送り返します。 この前に、選択された保護リンクが先取りできた交通を運ぶなら、奴隷は、この交通にリンクを使用するのを止めます(すなわち、交通は、奴隷によって落とされて、リンクの中、または、保護リンクから進められません)。 そして、それは通常の交通を選択された保護リンクを送り始めます。
5. When the master receives the Switchover Response, it starts
sending and receiving the traffic that was previously carried
on the now-failed link over the new link.
5. マスターがSwitchover Responseを受け取るとき、それは、以前に現在失敗したリンクの上に新しいリンクの上まで運ばれた交通を、送って、受け始めます。
Note: Although this mechanism implies more traffic dropped than
necessary, it is preferred over possible misconnections during the
recovery process.
以下に注意してください。 このメカニズムは、必要とするより交通が低下したのを含意しますが、可能な付け違いよりそれは回復の過程の間好まれます。
From the description above, it is clear that M:N span restoration (involving LSP local recovery) MAY require up to three messages for each working link being switched: a failure indication message, a Switchover Request message, and a Switchover Response message.
記述によって、上では、M: N長さ回復(LSPの地方の回復にかかわる)が切り換えられるそれぞれの働くリンクへの最大3つのメッセージを必要とするのが、明確です: 失敗指示メッセージ、Switchover Requestメッセージ、およびSwitchover Responseメッセージ。
Lang, et al. Standards Track [Page 9] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[9ページ]RFC4426GMPLS回復
The following functionality is required for M:N span restoration:
以下の機能性がMに必要です: Nは回復にかかっています:
o Pre-emption MUST be supported to accommodate Extra Traffic.
o Extra Trafficを収容するために先取りを支持しなければなりません。
o Routing: A single TE link encompassing both sets of working and
protect links should be announced with a Link Protection Type
"Shared M:N". If Extra Traffic is supported over a set of the
protection links, then the bandwidth parameters for the set of
protection links MUST also be announced. The differentiation
between bandwidth for working and protect links is made using
priority mechanisms.
o ルート設定: 独身のTEは両方のセットの働きを取り囲みながらリンクして、保護します。リンクによるLink Protection Typeが発表される状態で「M: Nを共有した」ということであるはずです。 また、Extra Trafficが保護リンクの1セットについてサポートされるなら、保護リンクのセットのための帯域幅パラメタを発表しなければなりません。 リンクを保護してください。そして、働くための帯域幅の間の分化、優先権メカニズムを使用することで、作られています。
If there is a failure on a working link, then the affected
LSP(s) MUST be switched to a protection link, pre-empting Extra
Traffic if necessary. The bandwidth for the protection link
MUST be adjusted accordingly.
働くリンクの上に失敗があれば、影響を受けるLSP(s)を保護リンクに切り換えなければなりません、必要なら、Extra Trafficを先取りして。 それに従って、保護リンクへの帯域幅を調整しなければなりません。
o Signaling: To establish an LSP on the working link, the Link
Protection object/TLV indicating "Shared M:N" SHOULD be
included in the signaling request message for that LSP. To
establish an LSP on the protection link, the appropriate
priority (indicating Extra Traffic) SHOULD be used. These
objects/TLVs are defined in [RFC3471]. If the Link Protection
object/TLV is not used, link selection is a matter of local
policy.
o シグナリング: 働くリンクでは、Link Protection物/TLV表示が「M: Nを共有した」というLSP SHOULDを証明するには、そのLSPへのシグナリング要求メッセージで含められてください。 保護リンクの上のLSP、適切な優先権(Extra Trafficを示す)SHOULDを証明するには、使用されてください。 これらの物/TLVsは[RFC3471]で定義されます。 Link Protection物/TLVが使用されていないなら、リンク選択はローカルの方針の問題です。
o For link management, both nodes MUST have a consistent view of
the link protection association for the links. This can be
done using LMP [RFC4204] or via manual configuration.
o リンク管理のために、両方のノードには、リンクへのリンク保護協会の一貫した視点がなければなりません。 これはLMP[RFC4204]を使用し終わっているか、手動の構成であることができます。
2.5. Messages
2.5. メッセージ
The following messages are used in local span protection procedures.
以下のメッセージはローカルの長さ保護手順で使用されます。
These messages SHOULD be delivered reliably. Therefore, the protocol mechanisms used to deliver these messages SHOULD provide sequencing, acknowledgement, and retransmission. The protocol SHOULD also handle situations where the message(s) cannot be delivered.
これらはSHOULDを通信させます。確かに届けます。 したがって、プロトコルメカニズムは以前は、よくSHOULDが配列、承認、および「再-トランスミッション」を提供するというこれらのメッセージを送りました。 また、プロトコルSHOULDはメッセージを果たすことができない状況を扱います。
The messages described in the following subsections are abstract; their format and encoding will be described in separate documents.
以下の小区分で説明されたメッセージは抽象的です。 それらの形式とコード化は別々のドキュメントで説明されるでしょう。
2.5.1. Failure Indication Message
2.5.1. 失敗指示メッセージ
This message is sent from the slave to the master to indicate the identities of one or more failed working links. This message MAY not be necessary when the transport plane technology itself provides for such a notification.
1個以上の失敗した働くリンクのアイデンティティを示すためにこのメッセージを奴隷からマスターに送ります。 輸送機技術自体がそのような通知に備えるとき、このメッセージは必要でないかもしれません。
Lang, et al. Standards Track [Page 10] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[10ページ]RFC4426GMPLS回復
The number of links included in the message depends on the number of failures detected within a window of time by the sending node. A node MAY choose to send separate failure indication messages in the interest of completing the recovery for a given link within an implementation-dependent time constraint.
メッセージにリンクを含む数は時間の窓の中に送付ノードによって検出された失敗の数に依存します。 ノードは、実現依存する時間規制の中で与えられたリンクに回復を終了することのために別々の失敗指示メッセージを送るのを選ぶかもしれません。
2.5.2. Switchover Request Message
2.5.2. 転換要求メッセージ
Under bi-directional 1+1 span protection, this message is used to coordinate the selecting function at both nodes. This message originated at the node that detected the failure.
双方向の1+1長さ保護で、このメッセージは、両方のノードにおける選択機能を調整するのに使用されます。 ノードで溯源されて、それが失敗を検出したというこのメッセージ。
Under dedicated 1:1 and shared M:N span protection, this message is used as an LSP Switchover Request. This message is sent from the master node to the slave node (reliably) to indicate that the LSP(s) on the (failed) working link can be switched to an available protection link. If so, the ID of the protection link, as well as the LSP labels (if necessary), MUST be indicated. These identifiers MUST be consistent with those used in GMPLS signaling.
分配しているM: ひたむきな1:1とN長さ保護で、このメッセージはLSP Switchover Requestとして使用されます。 (失敗される)の働くリンクの上のLSP(s)を利用可能な保護リンクに切り換えることができるのを示すためにマスターノードから奴隷ノード(確かである)にこのメッセージを送ります。 そうだとすれば、保護リンクのID、およびLSPラベル(必要なら)を示さなければなりません。 これらの識別子はGMPLSシグナリングに使用されるそれらと一致しているに違いありません。
A working link may carry multiple LSPs. Since the normal traffic carried over the working link is switched to the protection link, it MAY be possible for the LSPs on the working link to be mapped to the protection link without re-signaling each individual LSP. For example, if link bundling [RFC4201] is used where the working and protect links are mapped to component links, and the labels are the same on the working and protection links, it MAY be possible to change the component links without needing to re-signal each individual LSP. Optionally, the labels MAY need to be explicitly coordinated between the two nodes. In this case, the Switchover Request message SHOULD carry the new label mappings.
働くリンクは複数のLSPsを運ぶかもしれません。 働くリンクの上まで運ばれた通常の交通が保護リンクに切り換えられるので、働くリンクの上のLSPsがそれぞれの個々のLSPに再合図しないで保護リンクに写像されるのは、可能であるかもしれません。 保護してください。そして、リンクバンドリング[RFC4201]が例えば使用されている、どこ、働き、コンポーネントがそれぞれの個々のLSPに再合図する必要はなくてリンクされるのは、リンクがコンポーネントリンクに写像されて、ラベルが働きと保護リンクで同じであることが変化に可能であってもよいです。 任意に、ラベルは、2つのノードの間で明らかに調整される必要があるかもしれません。 この場合、Switchover RequestメッセージSHOULDは新しいラベルマッピングを運びます。
The master may not be able to find protection links to accommodate all failed working links. Thus, if this message is generated in response to a Failure Indication message from the slave, then the set of failed links in the message MAY be a sub-set of the links received in the Failure Indication message. Depending on time constraints, the master may switch the normal traffic from the set of failed links in smaller batches. Thus, a single failure indication message MAY result in the master sending more than one Switchover Request message to the same slave node.
マスターは、すべての失敗した働くリンクを収容するために保護リンクを見つけることができないかもしれません。 したがって、このメッセージが奴隷からのFailure Indicationメッセージに対応して発生するなら、メッセージの失敗したリンクのセットはFailure Indicationメッセージに受け取られたリンクの部分集合であるかもしれません。 時間規制によって、マスターは失敗したリンクのセットから、よりわずかなバッチで通常の交通を切り換えるかもしれません。 したがって、ただ一つの失敗指示メッセージは1つ以上のSwitchover Requestメッセージを同じ奴隷ノードに送るマスターをもたらすかもしれません。
2.5.3. Switchover Response Message
2.5.3. 転換応答メッセージ
This message is sent from the slave to the master (reliably) to indicate the completion (or failure) of switchover at the slave. In this message, the slave MAY indicate that it cannot switch over to the corresponding free link for some reason. In this case, the
奴隷で転換の完成(または、失敗)を示すために奴隷からマスター(確かである)にこのメッセージを送ります。 このメッセージでは、奴隷は、それがある理由で対応する無料のリンクに切り替わることができないのを示すかもしれません。 この場合
Lang, et al. Standards Track [Page 11] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[11ページ]RFC4426GMPLS回復
master and slave notify the user (operator) of the failed switchover. A notification of the failure MAY also be used as a trigger in an end-to-end recovery.
マスターと奴隷は失敗した転換についてユーザ(オペレータ)に通知します。また、失敗の通知は引き金として終わりから終わりへの回復に使用されるかもしれません。
2.6. Preventing Unintended Connections
2.6. 故意でないコネクションズを防ぎます。
An unintended connection occurs when traffic from the wrong source is delivered to a receiver. This MUST be prevented during protection switching. This is primarily a concern when the protection link is being used to carry Extra Traffic. In this case, it MUST be ensured that the LSP traffic being switched from the (failed) working link to the protection link is not delivered to the receiver of the pre- empted traffic. Thus, in the message flow described above, the master node MUST disconnect (any) pre-empted traffic on the selected protection link before sending the Switchover Request. The slave node MUST also disconnect pre-empted traffic before sending the Switchover Response. In addition, the master node SHOULD start receiving traffic for the protected LSP from the protection link. Finally, the master node SHOULD start sending protected traffic on the protection link upon receipt of the Switchover Response.
間違ったソースからの交通を受信機に渡すとき、故意でない接続は起こります。保護の切り換えの間、これを防がなければなりません。 保護リンクがExtra Trafficを運ぶのに使用されているとき、これは主として関心です。 この場合、保護リンクへの(失敗される)の働くリンクから切り換えられるLSP交通があらかじめemptedされた交通の受信機に渡されないのを確実にしなければなりません。 したがって、上で説明されたメッセージ流動では、Switchover Requestを送る前に、マスターノードは選択された保護リンクにおける(いずれ)の先取りされた交通を外さなければなりません。 また、Switchover Responseを送る前に、奴隷ノードは先取りされた交通を外さなければなりません。 さらに、マスターノードSHOULDは保護されたLSPのために保護リンクから交通を受け始めます。 最終的に、マスターノードSHOULDスタート発信はSwitchover Responseを受け取り次第保護リンクにおける交通を保護しました。
3. End-to-End (Path) Protection and Restoration
3. 終わりから終わりへの(経路)保護と王政復古
End-to-end path protection and restoration refer to the recovery of an entire LSP from the initiator to the terminator. Suppose the primary path of an LSP is routed from the initiator (Node A) to the terminator (Node B) through a set of intermediate nodes.
終わりから終わりへの経路保護と回復は全体のLSPの創始者からターミネータまでの回復について言及します。 LSPの第一の経路が1セットの中間的ノードを通して創始者(ノードA)からターミネータ(ノードB)まで発送されると仮定してください。
The following subsections describe three previously proposed end-to- end protection schemes and the functional steps needed to implement them.
以下の小区分は以前に提案された3終わりから終わりへの保護計画について説明します、そして、機能段階はそれらを実行する必要がありました。
3.1. Unidirectional 1+1 Protection
3.1. 単方向の1+1保護
A dedicated, resource-disjoint alternate path is pre-established to protect the LSP. Traffic is simultaneously sent on both paths and received from one of the functional paths by the end nodes A and B.
ひたむきで、リソースでばらばらになっている代替パスは、LSPを保護するためにあらかじめ確立されます。 エンドノードAとBは交通を同時に、両方の経路で送って、機能的な経路の1つから受けます。
There is no explicit signaling involved with this mode of protection.
保護のこの方法にかかわるどんな明白なシグナリングもありません。
3.2. Bi-directional 1+1 Protection
3.2. 双方向の1+1保護
A dedicated, resource-disjoint alternate path is pre-established to protect the LSP. Traffic is simultaneously sent on both paths; under normal conditions, the traffic from the working path is received by nodes A and B (in the appropriate directions). A failure affecting the working path results in both A and B switching to the traffic on the protection path in the respective directions.
ひたむきで、リソースでばらばらになっている代替パスは、LSPを保護するためにあらかじめ確立されます。 同時に、両方の経路で交通を送ります。 正常な状況では、ノードAとB(適切な方向への)は働く経路からの交通を受けます。 働く経路に影響する失敗は、それぞれの指示に基づき保護経路における交通に切り替わりながら、AとBの両方をもたらします。
Lang, et al. Standards Track [Page 12] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[12ページ]RFC4426GMPLS回復
Note that this requires coordination between the end nodes to switch to the protection path.
これが、エンドノードの間のコーディネートが保護経路に切り替わるのを必要とすることに注意してください。
The basic steps in bi-directional 1+1 path protection are as follows:
双方向の1+1経路保護における基本的なステップは以下の通りです:
o Failure detection: There are two possibilities for this.
o 失敗検出: これのための2つの可能性があります。
1. A node in the working path detects a failure event. Such
a node MUST send a Failure Indication message toward the
upstream or/and downstream end node of the LSP (node A or
B). This message MAY be forwarded along the working path
or routed over a different path if the network has
general routing intelligence.
1. 働く経路のノードは失敗出来事を検出します。 そのようなノードはLSP(ノードAかB)の上流か/と川下のエンドノードに向かってFailure Indicationメッセージを送らなければなりません。 ネットワークに一般的なルーティング知性があるなら、このメッセージを働く経路に沿って転送するか、または異なった経路の上に発送するかもしれません。
Mechanisms provided by the data transport plane MAY also
be used for this, if available.
また、データ輸送機によって提供されたメカニズムも、これに中古であって、利用可能であるかもしれません。
2. The end nodes (A or B) detect the failure themselves
(e.g., loss of signal).
2. エンドノード(AかB)は自分たちで失敗を検出します(例えば、信号の損失)。
o Switchover: The action taken when an end node detects a failure
in the working path is as follows: Start receiving from the
protection path; at the same time, send a Switchover Request
message to the other end node to enable switching at the other
end.
o 転換: エンドノードが働く経路に失敗を検出すると取られた行動は以下の通りです: 保護経路から受信し始めてください。 同時に、可能にするもう一方の端のときに切り替わるもう片方のエンドノードにSwitchover Requestメッセージを送ってください。
The action taken when an end node receives a Switchover Request
message is as follows:
エンドノードがSwitchover Requestメッセージを受け取るとき取られた行動は以下の通りです:
- Start receiving from the protection path; at the same
time, send a Switchover Response message to the other end
node.
- 保護経路から受信し始めてください。 同時に、Switchover Responseメッセージをもう片方のエンドノードに送ってください。
GMPLS signaling mechanisms MAY be used to (reliably) signal the Failure Indication message, as well as the Switchover Request and Response message. These messages MAY be forwarded along the protection path if no other routing intelligence is available in the network.
GMPLSシグナル伝達機構はFailure Indicationメッセージに(確かに)合図するのに使用されるかもしれません、Switchover RequestとResponseメッセージと同様に。 他のどんなルーティング知性もネットワークで利用可能でないなら、保護経路に沿ってこれらのメッセージを転送するかもしれません。
3.2.1. Identifiers
3.2.1. 識別子
LSP Identifier: A unique identifier for each LSP. The LSP identifier is within the scope of the Source ID and Destination ID.
LSP識別子: 各LSPに、ユニークな識別子。 Source IDとDestination IDの範囲の中にLSP識別子があります。
Source ID: ID of the source (e.g., IP address).
ソースID: ソース(例えば、IPアドレス)のID。
Destination ID: ID of the destination (e.g., IP address).
目的地ID: 目的地(例えば、IPアドレス)のID。
Lang, et al. Standards Track [Page 13] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[13ページ]RFC4426GMPLS回復
3.2.2. Nodal Information
3.2.2. こぶのような情報
Each node that is on the working or protection path of an LSP MUST have knowledge of the LSP identifier. If the network does not provide routing intelligence, nodal information MAY also include previous and next nodes in the LSP so that restoration-related messages can be forwarded properly. When the network provides general routing intelligence, messages MAY be forwarded along paths other than that of the LSP.
LSP MUSTの働きか保護経路で心得があることであるLSP識別子の各ノード。 また、ネットワークがルーティング知性を提供しないなら、こぶのような情報は、適切に回復関連のメッセージを転送できるようにLSPの前で次のノードを含むかもしれません。 ネットワークが一般的なルーティング知性を提供するとき、LSPのもの以外の経路に沿ってメッセージを転送するかもしれません。
At the end-point nodes, the working and protection paths MUST be associated. The association of these paths MAY be either provisioned using signaling or MAY be configured when LSP provisioning does not involve signaling (e.g., provisioning through a management system). The related association information MUST remain until the LSP is explicitly de-provisioned.
エンドポイントノードでは、運用と保護経路は関連しているに違いありません。 これらの経路の協会はシグナリングを使用することで食糧を供給されるか、または食糧を供給するのがするLSPが、合図することを伴わないと(例えば、マネージメントシステムを通した食糧を供給すること)構成されているかもしれないことであるかもしれません。 LSPが反-明らかに食糧を供給されるまで、関連する協会情報は残らなければなりません。
3.2.3. End-to-End Failure Indication Message
3.2.3. 終わりから終わりへの失敗指示メッセージ
This message is sent (reliably) by an intermediate node toward the source of an LSP. For instance, such a node might have attempted local span protection and failed. This message MAY not be necessary if the data transport layer provides mechanisms for the notification of LSP failure by the endpoints (i.e., if LSP endpoints are co- located with a corresponding data (transport) maintenance/recovery domain).
中間的ノードはLSPの源に向かってこのメッセージを送ります(確かに)。 例えば、そのようなノードは、地方の長さ保護を試みて、失敗したかもしれません。 データトランスポート層が終点のそばでLSPの故障の通知にメカニズムを提供するなら(すなわち、LSP終点が対応するデータ(輸送)維持/回復ドメインで共同見つけられているなら)、このメッセージは必要でないかもしれません。
Consider a node that detects a link failure. The node MUST determine the identities of all LSPs that are affected by the failure of the link and send an End-to-End Failure Indication message to the source of each LSP. For scalability reasons, Failure Indication messages MAY contain the identity and the status of multiple LSPs rather than a single one. Each intermediate node receiving such a message MUST forward the message to the appropriate next node such that the message would ultimately reach the LSP source. However, there is no requirement that this message flows toward the source along the same path as the failed LSP. Furthermore, if an intermediate node is itself generating a Failure Indication message, there SHOULD be a mechanism to suppress all but one source of Failure Indication messages. Finally, the Failure Indication message MUST be sent reliably from the node detecting the failure to the LSP source. Reliability MAY be achieved, for example, by retransmitting the message until an acknowledgement is received. However, retransmission of Failure Indication messages SHOULD not cause further message drops. This MAY be achieved through the appropriate configuration and use of congestion and flow control mechanisms.
リンクの故障を検出するノードを考えてください。 ノードは、リンクの失敗で影響を受けるすべてのLSPsのアイデンティティを決定して、Endから終わりへのFailure IndicationメッセージをそれぞれのLSPの源に送らなければなりません。 スケーラビリティ理由で、Failure Indicationメッセージはただ一つのものよりむしろ複数のLSPsのアイデンティティと状態を含むかもしれません。 そのようなメッセージを受け取るそれぞれの中間的ノードは、メッセージが結局LSPソースに届くように、次の適切なノードにメッセージを転送しなければなりません。 しかしながら、このメッセージが同じ経路に沿った失敗したLSPとしてのソースに向かって流れるという要件が全くありません。 その上、中間的ノードであるなら発生自体がそこのFailure Indicationメッセージである、SHOULD、Failure Indicationメッセージの1つの源以外のすべてを抑圧するメカニズムになってください。 最終的に、失敗を検出するノードからLSPソースにFailure Indicationメッセージを確かに送らなければなりません。 例えば、信頼性は、承認が受け取られているまでメッセージを再送することによって、獲得されるかもしれません。 しかしながら、SHOULDがさらなるメッセージを引き起こさないFailure Indicationメッセージの「再-トランスミッション」は低下します。 これは混雑とフロー制御メカニズムの適切な構成と使用で達成されるかもしれません。
Lang, et al. Standards Track [Page 14] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[14ページ]RFC4426GMPLS回復
3.2.4. End-to-End Failure Acknowledgement Message
3.2.4. 終わりから終わりへの失敗確認メッセージ
This message is sent by the source node to acknowledge the receipt of an End-to-End Failure Indication message. This message is sent to the originator of the Failure Indication message. The Acknowledge message SHOULD be sent for each Failure Indication Message received. Each intermediate node receiving the Failure Acknowledgement message MUST forward it toward the destination of the message. However, there is no requirement that this message flows toward the destination along the same path as the failed LSP.
ソースノードでこのメッセージを送って、Endから終わりへのFailure Indicationメッセージの領収書を受け取ったことを知らせます。 Failure Indicationメッセージの創始者にこのメッセージを送ります。 AcknowledgeはSHOULDを通信させます。受け取られた各Failure Indication Messageには、送ってください。 Failure Acknowledgementメッセージを受け取るそれぞれの中間的ノードはメッセージの目的地に向かってそれを送らなければなりません。 しかしながら、失敗したLSPと同じ経路に沿ってこのメッセージが目的地に向かって流れるという要件が全くありません。
This message MAY not be required if other means of ensuring reliable message delivery are used.
信頼できるメッセージ配送を確実にする他の手段が使用されているなら、このメッセージは必要でないかもしれません。
3.2.5. End-to-End Switchover Request Message
3.2.5. 終わりから終わりへの転換要求メッセージ
This message is generated by the source node receiving an indication of failure in an LSP. It is sent to the LSP destination, and it carries the identifier of the LSP being restored. The End-to-End Switchover Request message MUST be sent reliably from the source to the destination of the LSP.
このメッセージはLSPの失敗のしるしを受けるソースノードで発生します。 LSPの目的地にそれを送ります、そして、それは返されるLSPに関する識別子を運びます。 Endから終わりへのSwitchover RequestメッセージをソースからLSPの目的地に確かに送らなければなりません。
3.2.6. End-to-End Switchover Response Message
3.2.6. 終わりから終わりへの転換応答メッセージ
This message is sent by the destination node receiving an End-to-End Switchover Request message toward the source of the LSP. This message SHOULD identify the LSP being switched over. This message MUST be transmitted in response to each End-to-End Switchover Request message received and MAY indicate either a positive or negative outcome.
Endから終わりへのSwitchover RequestメッセージをLSPの源に向かって受け取る目的地ノードはこのメッセージを送ります。 このメッセージSHOULDは転換されるLSPを特定します。このメッセージは、Switchover Requestメッセージが得た各Endから端に対応して伝えなければならなくて、肯定しているか否定している結果を示すかもしれません。
3.3. Shared Mesh Restoration
3.3. 共有されたメッシュ王政復古
Shared mesh restoration refers to schemes under which protection paths for multiple LSPs share common link and node resources. Under these schemes, the protection capacity is pre-reserved, i.e., link capacity is allocated to protect one or more LSPs, but explicit action is required to instantiate a specific protection LSP. This requires restoration signaling along the protection path. Typically, the protection capacity is shared only amongst LSPs whose working paths are physically diverse. This criterion can be enforced when provisioning the protection path. Specifically, provisioning-related signaling messages may carry information about the working path to nodes along the protection path. This can be used as call admission control to accept/reject connections along the protection path based on the identification of the resources used for the primary path.
共有されたメッシュ回復は複数のLSPsのための保護経路が普通リンクとノードリソースを共有する計画について言及します。 これらの計画の下では、保護容量がプレ予約されている、1LSPsを保護するためにすなわち、リンク容量を割り当てますが、特異的予防LSPを例示するために明白な動作を必要とします。 これは保護経路に沿って回復シグナリングを必要とします。 通常、保護容量は働く経路が物理的に多様であるLSPsだけの中で共有されます。 保護経路に食糧を供給するとき、この評価基準を励行されることができます。 明確に、食糧を供給する関連のシグナリングメッセージは保護経路に沿って働く経路の情報をノードまで運ぶかもしれません。 運用資金の識別に基づく保護経路に沿って第一の経路に接続を受け入れるか、または拒絶するのにコール許可コントロールとしてこれを使用できます。
Lang, et al. Standards Track [Page 15] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[15ページ]RFC4426GMPLS回復
Thus, shared mesh restoration is designed to protect an LSP after a single failure event, i.e., a failure that affects the working path of at most one LSP sharing the protection capacity. It is possible that a protection path may not be successfully activated when multiple, concurrent failure events occur. In this case, shared mesh restoration capacity may be claimed for more than one failed LSP and the protection path can be activated only for one of them (at most).
したがって、共有されたメッシュ復元模型は、単一の失敗出来事(すなわち、高々保護容量を共有する1LSPの働く経路に影響する失敗)の後にLSPを保護するように設計されています。 複数の、そして、同時発生の失敗出来事が起こるとき、保護経路が首尾よく活性化しないのは、可能です。 この場合、共有されたメッシュ回復容量は1失敗したLSPに代金を請求されるかもしれません、そして、保護経路はそれら(高々)の1つのためだけに活性化できます。
For implementing shared mesh restoration, the identifier and nodal information related to signaling along the control path are as defined for 1+1 protection in Sections 3.2.1 and 3.2.2. In addition, each node MUST also keep (local) information needed to establish the data plane of the protection path. This information MUST indicate the local resources to be allocated, the fabric cross-connect to be established to activate the path, etc. The precise nature of this information would depend on the type of node and LSP (the GMPLS signaling document describes different type of switches [RFC3471]). It would also depend on whether the information is fine or coarse- grained. For example, fine-grained information would indicate pre- selection of all details pertaining to protection path activation, such as outgoing link, labels, etc. Coarse-grained information, on the other hand, would allow some details to be determined during protection path activation. For example, protection resources may be pre-selected at the level of a TE link, while the selection of the specific component link and label occurs during protection path activation.
シグナリングに関連する共有されたメッシュ回復、識別子、およびこぶのような情報を実行して、コントロール経路に沿って.2がセクション3.2.1と3.2における1+1保護のために定義されるようにあるので。 また、さらに、各ノードは保護経路のデータ飛行機を設立するのに必要である(地方)の情報を保たなければなりません。 この情報は割り当てられるローカル資源を示さなければなりません、経路を活性化するのなどために設立されるべき織物十字接続 この情報の正確な本質はノードとLSPのタイプに頼っているでしょう(GMPLSシグナリングドキュメントは異なったタイプのスイッチ[RFC3471]について説明します)。 また、それは情報が粒状であることで詳しいか粗いかよるでしょう。 例えば、きめ細かに粒状の情報は保護経路起動に関係するすべての詳細のプレ品揃えを示すでしょう、出発しているリンク、ラベルなどのように 他方では、下品な情報は、保護経路起動の間、いくつかの詳細が決定しているのを許容するでしょう。 例えば、保護リソースはTEリンクのレベルで前選択されるかもしれません、特定のコンポーネントリンクとラベルの選択は保護経路起動の間起こりますが。
While the coarser specification allows some flexibility in the selection of the precise resource to activate, it also adds complexity in decision making and signaling during the time-critical restoration phase. Furthermore, the procedures for the assignment of bandwidth to protection paths MUST take into account the total resources in a TE link so that single-failure survivability requirements are satisfied.
より粗い仕様は活性化する正確なリソースの選択における何らかの柔軟性を許容しますが、また、それは時間きわどい回復段階の間意志決定とシグナリングにおける複雑さを加えます。 その上、保護経路への帯域幅の課題のための手順がTEリンクで総リソースを考慮に入れなければならないので、ただ一つの失敗生存性要件は満たされています。
3.3.1. End-to-End Failure Indication and Acknowledgement Message
3.3.1. 終わりから終わりへの失敗指示と確認メッセージ
The End-to-End failure indication and acknowledgement procedures and messages are as defined in Sections 3.2.3 and 3.2.4.
セクション3.2.3と3.2で定義されて、失敗指示、承認手順、およびメッセージがあるEndから終わりへの.4。
3.3.2. End-to-End Switchover Request Message
3.3.2. 終わりから終わりへの転換要求メッセージ
This message is generated by the source node receiving an indication of failure in an LSP. It is sent to the LSP destination along the protection path, and it identifies the LSP being restored. If any intermediate node is unable to establish cross-connects for the protection path, then it is desirable that no other node in the path
このメッセージはLSPの失敗のしるしを受けるソースノードで発生します。 保護経路に沿ったLSPの目的地にそれを送ります、そして、それは返されるLSPを特定します。 どれか中間的ノードが保護経路に十字接続を確立できないならそんなに別に望ましい、経路のノード
Lang, et al. Standards Track [Page 16] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[16ページ]RFC4426GMPLS回復
establishes cross-connects for the path. This would allow shared mesh restoration paths to be efficiently utilized.
十字接続を経路に確立します。 これは、共有されたメッシュ回復経路が効率的に利用されるのを許容するでしょう。
The End-to-End Switchover message MUST be sent reliably from the source to the destination of the LSP along the protection path.
保護経路に沿ってEndから終わりへのSwitchoverメッセージをソースからLSPの目的地に確かに送らなければなりません。
3.3.3. End-to-End Switchover Response Message
3.3.3. 終わりから終わりへの転換応答メッセージ
This message is sent by the destination node receiving an End-to-End Switchover Request message toward the source of the LSP, along the protection path. This message SHOULD identify the LSP that is being switched over. Prior to activating the secondary bandwidth at each hop along the path, Extra Traffic (if used) MUST be dropped and not forwarded.
Endから終わりへのSwitchover RequestメッセージをLSPの源に向かって受け取る目的地ノードでこのメッセージを送ります、保護経路に沿って。 このメッセージSHOULDは転換されているLSPを特定します。経路に沿った各ホップで二次帯域幅を動かす前に、Extra Traffic(使用されるなら)を落として、進めてはいけません。
This message MUST be transmitted in response to each End-to-End Switchover Request message received.
Switchover Requestメッセージが得た各Endから端に対応してこのメッセージを送らなければなりません。
4. Reversion and Other Administrative Procedures
4. 逆戻りと他の行政手続
Reversion refers to the process of moving an LSP back to the original working path after a failure is cleared and the path is repaired. Reversion applies both to local span and end-to-end path-protected LSPs. Reversion is desired for the following reasons. First, the protection path may not be optimal in comparison to the working path from a routing and resource consumption point of view. Second, moving an LSP to its working path allows the protection resources to be used to protect other LSPs. Reversion has the disadvantage of causing a second service disruption. Use of reversion is at the option of the operator. Reversion implies that a working path remains allocated to the LSP that was originally routed over it, even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption to the customer. This can be achieved using a "bridge-and-switch" approach (often referred to as make-before-break).
逆戻りは失敗がクリアされて、経路が修理された後に元の働く経路にLSPを戻らせる過程を示します。 逆戻りは地方の長さと終わりから終わりへの経路で保護されたLSPsに両方を適用します。 逆戻りは以下の理由で望まれています。 まず最初に、保護経路は比較でルーティングとリソース消費観点からの働く経路に最適でないかもしれません。 2番目に、LSPを働く経路に動かすのは、保護リソースが他のLSPsを保護するのに使用されるのを許容します。 逆戻りには、セカンドサービス分裂を引き起こす不都合があります。 オペレータの選択には逆戻りの使用があります。 逆戻りは、働く経路が元々それの上に発送されたLSPに割り当てたままで残っているのを含意します、失敗の後にさえ。 逆戻りが最小量のサービスの崩壊で顧客に働くメカニズムを持っているのは重要です。 「橋とスイッチ」アプローチ(しばしば以前開閉しているのに言及される)を使用することでこれを達成できます。
The basic steps involved in bridge-and-switch are as follows:
橋とスイッチにかかわる基本的なステップは以下の通りです:
1. The source node commences the process by "bridging" the normal
traffic onto both the working and the protection paths (or
links in the case of span protection).
1. ソースノードは、通常の交通が働きと保護経路の両方(または、長さ保護の場合におけるリンク)に「橋を架ける」であることによって、過程を始めます。
2. Once the bridging process is complete, the source node sends a
Bridge and Switch Request message to the destination,
identifying the LSP and other information necessary to perform
reversion. Upon receipt of this message, the destination
2. 橋を架けることの過程がいったん完全になると、ソースノードはBridgeとSwitch Requestメッセージを目的地に送ります、逆戻りを実行するためにLSPと他の必要情報を特定して。 このメッセージ、目的地を受け取り次第
Lang, et al. Standards Track [Page 17] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[17ページ]RFC4426GMPLS回復
selects the traffic from the working path. At the same time,
it bridges the transmitted traffic onto both the working and
protection paths.
働く経路からの交通を選択します。 同時に、それは働きと保護経路の両方に伝えられた交通に橋を架けます。
3. The destination then sends a Bridge and Switch Response message
to the source confirming the completion of the operation.
3. そして、目的地は操作の完成を確認するソースにBridgeとSwitch Responseメッセージを送ります。
4. When the source receives this message, it switches to receive
from the working path, and stops transmitting traffic on the
protection path. The source then sends a Bridge and Switch
Completed message to the destination confirming that the LSP
has been reverted.
4. 情報筋がこのメッセージを受け取るとき、それは、働く経路から受信するために切り替わって、保護経路における交通を伝えるのを止めます。 そして、ソースはLSPが振り向けられたと確認する目的地にBridgeとSwitch Completedメッセージを送ります。
5. Upon receipt of this message, the destination stops
transmitting along the protection path and de-activates the LSP
along this path. The de-activation procedure should remove the
crossed connections along the protection path (and frees the
resources to be used for restoring other failures).
5. このメッセージを受け取り次第、目的地は、保護経路に沿って伝わるのを止めて、この経路に沿って反-LSPを動かします。 非活性化手順は保護経路(そして、他の失敗を回復するのに使用されるためにリソースを解放する)に沿って交差している接続を外すべきです。
Administrative procedures other than reversion include the ability to force a switchover (from working to protection or vice versa) and locking out switchover, i.e., preventing an LSP from moving from working to protection administratively. These administrative conditions have to be supported by signaling.
すなわち、LSPが働きから保護まで行政上動くのを防ぎながら、逆戻り以外の行政手続は、転換(逆もまた同様に保護に取り組むのからの)を強制する能力と転換を締め出すのを含んでいます。 これらの管理状態はシグナリングによって支持されなければなりません。
5. Discussion
5. 議論
5.1. LSP Priorities During Protection
5.1. 保護の間のLSPプライオリティ
Under span protection, a failure event could affect more than one working link and there could be fewer protection links than the number of failed working links. Furthermore, a working link may contain multiple LSPs of varying priority. Under this scenario, a decision must be made as to which working links (and therefore LSPs) should be protected. This decision MAY be based on LSP priorities.
長さ保護で、失敗出来事は1個以上の働くリンクに影響するかもしれません、そして、失敗した働くリンクの数より少ない保護リンクがあるかもしれません。 その上、働くリンクは異なった優先権の複数のLSPsを含むかもしれません。 このような筋書で、どの働くリンク(そして、したがって、LSPs)が保護されるべきであるかに関して決定をしなければなりません。 この決定はLSPプライオリティに基づくかもしれません。
In general, a node might detect failures sequentially, i.e., all failed working links may not be detected simultaneously, but only sequentially. In this case, as per the proposed signaling procedures, LSPs on a working link MAY be switched over to a given protection link, but another failure (of a working link carrying higher priority LSPs) may be detected soon afterward. In this case, the new LSPs may bump the ones previously switched over the protection link.
一般に、ノードが失敗を連続して検出するかもしれなくて、すなわち、すべての失敗した働くリンクが同時に、検出されるのではなく、連続するだけ、そして検出されるかもしれません。 この場合、提案されたシグナリング手順に従って働くリンクの上のLSPsは与えられた保護リンクに転換されるかもしれませんが、別の失敗(働くリンクが、より高い優先度LSPsを運ぶのについて)はその後、すぐ、検出されるかもしれません。 この場合、新しいLSPsは以前に保護リンクの上に切り換えられたものに突き当たるかもしれません。
In the case of end-to-end shared mesh restoration, priorities MAY be implemented for allocating shared link resources under multiple failure scenarios. As described in Section 3.3, more than one LSP
終わりから終わりへのメッシュ共有された回復の場合では、プライオリティは、複数の失敗シナリオの下に共有されたリンクリソースを割り当てるために実行されるかもしれません。 セクション3.3の、そして、あるLSPより多くの説明されたコネとして
Lang, et al. Standards Track [Page 18] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[18ページ]RFC4426GMPLS回復
can claim shared resources under multiple failure scenarios. If such resources are first allocated to a lower-priority LSP, they MAY have to be reclaimed and allocated to a higher-priority LSP.
複数の失敗シナリオの下で共用資源を要求できます。 最初にそのようなリソースを低優先度LSPに割り当てるなら、より高い優先度LSPにそれらを開墾して、割り当てなければならないかもしれません。
6. Security Considerations
6. セキュリティ問題
There are a number of security threats that MAY be experienced due to the exchange of messages and information, as detailed in this document. Some examples include interception, spoofing, modification, and replay of control messages. Therefore, the following security requirements are applicable to the mechanisms of this document.
メッセージと情報の交換のため経験されるかもしれない多くの軍事的脅威があります、本書では詳しく述べられるように。 いくつかの例がコントロールメッセージの妨害、スプーフィング、変更、および再生を含んでいます。 したがって、以下のセキュリティ要件はこのドキュメントのメカニズムに適切です。
o Signaling MUST be able to provide authentication, integrity,
and protection against replay attacks.
o シグナリングは反射攻撃に対する認証、保全、および保護を提供できなければなりません。
o Privacy and confidentiality are not required. Only
authentication is required to ensure that the signaling
messages are originating from the right place and have not been
modified in transit.
o プライバシーと秘密性は必要ではありません。 認証だけが、シグナリングメッセージが適当な場所から発しているのを確実にして、トランジットで変更されていないように必要です。
o Protection of the identity of the data plane end-points (in
Failure Indication messages) is not required
o データ飛行機エンドポイント(Failure Indicationメッセージの)のアイデンティティの保護は必要ではありません。
The consequences of poorly secured protection may increase the risk of triggering recovery actions under false Failure Indication messages, including LSP identifiers that are not under failure. Such information could subsequently trigger the initiation of "false" recovery actions while there are no reasons to do so. Additionally, if the identification of the LSP is tampered with from a Failure Indication message, recovery actions will involve nodes for which the LSPs do not indicate any failure condition or for which no Failure Indication message has been received. The consequences of such actions is unpredictable and MAY lead to de-synchronisation between the control and the data plane, as well as increase the risk of misconnections. Moreover, the consequences of poorly applied protection may increase the risk of misconnection. In particular, when Extra Traffic is involved, it is easily possible to deliver the wrong traffic to the wrong destination. Similarly, an intrusion that sets up what appears to be a valid protection LSP and then causes a fault may be able to divert traffic.
不十分に安全にされた保護の結果は誤ったFailure Indicationメッセージの下で回復動作の引き金となるという危険を増加させるかもしれません、失敗の下にないLSP識別子を含んでいて。 そうする理由が全くない間、そのような情報は次に、「誤った」回復動作の開始の引き金となるかもしれません。 さらに、LSPの識別がFailure Indicationメッセージからいじられると、回復動作はLSPsがどんな失敗状態も示さないか、またはFailure Indicationメッセージが全く受け取られていないノードにかかわるでしょう。 そのような動作の結果は、予測できないで、コントロールとデータ飛行機の間の反-連動につながって、付け違いの危険を増加させるかもしれません。 そのうえ、不十分に適用された保護の結果は付け違いの危険を増加させるかもしれません。 Extra Trafficがかかわるとき、間違った交通を間違った送付先に届けるのは容易に特に、可能です。 同様に、有効な保護LSPであるように見えることをセットアップして、次に欠点を引き起こす押しつけは交通を紛らすことができるかもしれません。
Moreover, tampering with a routing information exchange may also have an effect on traffic engineering. Therefore, any mechanisms used for securing and authenticating the transmission of routing information SHOULD be applied in the present context.
そのうえ、また、ルーティング情報交換をいじると、影響は交通工学に与えられるかもしれません。 したがって、適用されていて、どんなメカニズムも、ルーティング情報の伝達を安全にして、認証するのに現在の文脈でSHOULDを使用しました。
Lang, et al. Standards Track [Page 19] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[19ページ]RFC4426GMPLS回復
7. Contributors
7. 貢献者
This document was the product of many individuals working together in the CCAMP WG Protection and Restoration design team. The following are the authors that contributed to this document:
このドキュメントはCCAMP WG Protectionと王政復古デザインチームで一緒に働いている多くの個人の製品でした。 ↓これはこのドキュメントに貢献した作者です:
Deborah Brungard (AT&T) 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラBrungard(AT&T)200秒間ローレルAve。 ミドルタウン、ニュージャージー 07748、米国
EMail: dbrungard@att.com
メール: dbrungard@att.com
Sudheer Dharanikota
Sudheer Dharanikota
EMail: sudheer@ieee.org
メール: sudheer@ieee.org
Jonathan P. Lang (Sonos) 223 East De La Guerra Street Santa Barbara, CA 93101, USA
ジョナサンP.ラング(Sonos)223東De Laグェルラ・通りサンタバーバラ、カリフォルニア 93101、米国
EMail: jplang@ieee.org
メール: jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
Guangzhi李(AT&T)180パーク・アベニュー、Florham公園、ニュージャージー 07932、米国
EMail: gli@research.att.com
メール: gli@research.att.com
Eric Mannie
エリック・マニー
EMail: eric_mannie@hotmail.com
メール: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
フランシスWellesplein、ディミトリPapadimitriou(アルカテル)の1B-2018のアントウェルペン(ベルギー)
EMail: dimitri.papadimitriou@alcatel.be
メール: dimitri.papadimitriou@alcatel.be
Lang, et al. Standards Track [Page 20] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[20ページ]RFC4426GMPLS回復
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
Bala Rajagopalanマイクロソフトインド開発センターハイデラバード(インド)
EMail: balar@microsoft.com
メール: balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
ヤコフRekhter(杜松)1194N.マチルダ・Avenueサニーベル、カリフォルニア 94089、米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4201]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC4203] エドKompella、K.、エドY.Rekhter、「一般化されたマルチプロトコルラベルを支持したOSPF拡張子は(GMPLS)を切り換えること」でのRFC4203(2005年10月)。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4204] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日
[RFC4205] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4205, October 2005.
エド[RFC4205]Kompella、K.、Y.Rekhter、エド、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(2005年10月)
Lang, et al. Standards Track [Page 21] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[21ページ]RFC4426GMPLS回復
8.2. Informative References
8.2. 有益な参照
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3945、2004年10月。
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
[RFC4427] エドマニー、E.、エドD.Papadimitriou、「一般化されたマルチプロトコルラベルのための回復(保護と王政復古)用語は(GMPLS)を切り換えること」でのRFC4427(2006年3月)。
Editors' Addresses
エディタのアドレス
Jonathan P. Lang Sonos, Inc. 223 East De La Guerra Street Santa Barbara, CA 93101
ジョナサンP.ラングSonos Inc.223の東De Laグェルラ・通りサンタバーバラ、カリフォルニア 93101
EMail: jplang@ieee.org
メール: jplang@ieee.org
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
Bala Rajagopalanマイクロソフトインド開発センターハイデラバード(インド)
Ph: +91-40-5502-7423 EMail: balar@microsoft.com
Ph: +91-40-5502-7423 メールしてください: balar@microsoft.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellesplein、1B-2018のアントウェルペン(ベルギー)
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be
Lang, et al. Standards Track [Page 22] RFC 4426 GMPLS Recovery Functional Specification March 2006
ラング、他 2006年の仕様行進のときに機能的な標準化過程[22ページ]RFC4426GMPLS回復
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Lang, et al. Standards Track [Page 23]
ラング、他 標準化過程[23ページ]
一覧
スポンサーリンク
