Network Working Group J. Lang, Ed.
Request for Comments: 4426 B. Rajagopalan, Ed.
Category: Standards Track D. Papadimitriou, Ed.
March 2006
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、一般化マルチプロトコルラベルスイッチング（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
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
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）は、ローカル（スパン）、セグメント、および/またはエンド・ツー・エンドの回復を受けてもよいです。ローカルスパン保護は二つの隣接スイッチ間（スパンの保護のために必要とリンクを介してルーティングされるようにマークされ、したがって、すべてのLSP）リンクの保護を意味します。セグメント保護は、2つのノード、すなわち、セグメントの境界ノード間のLSPセグメント（すなわち、ITU-T用語でSNC）の回復を指します。エンドツーエンドの保護は、出力ポートへの入口から全体のLSPの保護を指します。このドキュメントで説明エンド・ツー・エンドの復旧モデルは、ソースと宛先が全体LSPではなく、保護されたセグメントを参照セグメント保護に適用されます。複数の回復レベルを加え弾力のための単一のLSPによって同時に使用することができます。しかし、レベル間の相互作用が新スパン、セグメント、またはエンドツーエンドパスに切り替えているLSPの両方向におけるLSPの結果のいずれかの方向に影響を与えます。
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).
特に明記しない限り、このドキュメントの「リンク」へのすべての参照は、（単方向リンクのペアとして実現されてもよい）双方向のリンクを示しています。
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.
データトラフィックの流れが出口（宛先ノード）に入力（ソースノード）から定義されます。双方向のLSPのために、2つの異なるデータプレーン・フロー、LSPの各方向に対して1つが存在することに留意されたいです。この文書では、一般化マルチプロトコルラベルスイッチング（GMPLS）ベースの回復（すなわち、保護および復元）をサポートするためのプロトコル機能の説明を提示しています。プロトコル固有の形式、エンコーディング、およびメカニズムは仲間ドキュメントで説明します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]であると仮定されます。
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つの基本的なモデルがあります2つのノードAとBの間（作業）リンク私を考えてみましょう。最初は、1 + 1プロテクションと呼ばれます。このモデルでは、専用のリンクjは、リンクiを保護するために事前に割り当てられています。 LSPのトラフィックは完全入口ノードで両方のリンクiとjに架橋され、出口ノードは、選択機能（例えば、信号品質）に基づいて、IまたはJからの信号（すなわち、通常のトラフィック）を選択します。一方向1 + 1スパン保護（セクション2.1）の下で、各ノードA及びBは、作業リンクI又はプロテクションリンクjから信号を選択するように自律的に作用します。スパン保護（セクション2.2）2つのノードA及びB 1 + 1双方向の下で、それらは同一のリンクからの信号を選択するように、IまたはJの選択機能を調整します。
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のモデルの下では、Nのセット作業のリンクは通常、トラフィックのM = <NのNの動作リンクのいずれかで失敗の結果はそのM保護リンクの1つに切り替えた状態で、M保護リンクのセットで保護されています利用可能です。これは、典型的には、3段階のプロセスである：最初のデータプレーンの障害が出口ノードで検出され、（通知）が報告され、その後、保護リンクが選択され、そして最終的には、障害リンク上のLSPはプロテクションリンクに移動されます。復帰がサポートされている場合、第四の工程が含まれ、すなわち、作業リンクにトラフィックのリターン（作業リンクが障害から回復した場合）。 2.3節では、1：1スパン保護が記述されています。セクション2.4で、M：Nスパン保護は、ここで、M = <Nで、記載されています
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が、私は専用のリンクjが働きリンクiを保護するために事前に割り当てられ、一方向の1 + 1の保護下に2つのノードAとBの間のリンクを介してルーティングされると仮定します。 LSPのトラフィックは、恒久的に入口ノードで両方のリンク上でブリッジされ、そして出口ノードは、リンクのいずれかからIまたはJを通常のトラフィックを選択します。ノード（AまたはB）がスパンの故障を検出した場合、それは自律的に保護スパンからトラフィックを受信するためのプロセスを呼び出します。従って、ノードA iはLSPの方向Bにリンクからの信号を選択し、ノードBは、B方向にAにリンクjからの信号を選択することが可能です。
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リンクは作業リンクの帯域幅パラメータと一緒に、「+ 1 1を専用の」リンク保護タイプで発表されるべきです。リソースが解放/消費されると、TEリンクの帯域幅パラメータが調整されています。 IS-ISでのリンク保護タイプと帯域幅パラメータのエンコーディングは、[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シグナリング：リンク保護オブジェクト/ TLVは、そのLSPのための「専用1 + 1」リンク保護を要求するために使用されるべきです。この目的は、/ TLVは[RFC3471]で定義されています。リンク保護オブジェクト/ TLVを使用しない場合は、リンクの選択は、ローカルポリシーの問題です。フェイルオーバーが発生した場合に追加のシグナリングは必要ありません。
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リンク管理：両方のノードは、スパンのためのリンク保護協会の一貫したビューを持たなければなりません。これは、リンク管理プロトコル（LMP）[RFC4204]を使用して行うことができ、またはLMPが使用されていない場合、これは手動で設定する必要があります。
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が、私は専用のリンクjが働きリンクiを保護するために事前に割り当てられた、双方向の1 + 1の保護下に2つのノードAとBの間のリンクを介してルーティングされると仮定します。 LSPのトラフィックは完全両方のリンク上で複製され、そして通常の条件下で、リンクIからのトラフィックは、（適切な方向に）ノードA及びBによって受信されます。私はAとBの両方で結果各方向のリンクjのトラフィックへの切り替えリンクに影響を与える障害が発生。シグナル伝達のいくつかのフォームが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）は作業リンク（または作業リンクを介して信号品質の劣化）の故障を検出した場合、それは（プロテクションリンク上で受信を開始し、他のノードに確実に切替要求メッセージを送信すべきですそれぞれB又はA、）。このメッセージは、失敗した作業リンクのアイデンティティを示し、その他の関連情報を提供する必要があります。
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.切替要求メッセージを受信すると、ノードはプロテクションリンクからの受信を開始しなければならないと（それぞれ、AまたはB）は、他のノードへの切り替え応答メッセージを送信します。現用/保護スパンは、単一のリンクとしてルーティングおよびシグナリングにさらされている両方のため、切換えは、ルーティングおよびシグナリングに透明であるべきです。
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（一方向）に記載された手順に加えて、切替要求メッセージには、切替要求を通知するために使用されなければなりません。これは、LMP [RFC4204]を使用して行うことができます。根底にあるスパン（輸送）技術は、このような機構を提供する場合GMPLSベースのメカニズムが必要ではないかもしれないことに留意されたいです。
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.
AとBの間の専用リンクjが働いリンクiを保護するために事前に割り当てられ、1の保護：1の下に2つの隣接ノード、AとBを考えてみましょう。リンクjは（事前emptable）エキストラトラフィックを運ぶことができます。対応するLSP（S）の障害に影響リンク私の結果がjをリンクするために復元されます。リンクjの上に配線されている余分なトラフィックを復元する必要があるのLSPに対応するために横取りする必要があります。
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（複数可）保護リンクに移動する必要があります。プロテクションリンクに失敗した（作業）リンクからLSPを移動させる工程は、このノードが「マスター」と呼ばれるノード、AまたはBのいずれかによって開始されなければなりません。他のノードが「スレーブ」と呼ばれています。マスタとスレーブの決意は、構成情報またはプロトコル固有の要件に基づいてもよいです。
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（複数可）に保護リンクを割り当てるプロセスを呼び出します。
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.スレーブがリンク障害イベントを検出すると、障害表示メッセージを使用して、障害のマスターに通知します。マスタは、その後、（1）プロテクションリンクにLSPを移動するのと同じ手順を呼び出します。保護リンクが余分なトラフィックを伝送している場合、スレーブは余分なトラフィックのスパンを使用して停止します。
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（複数可）を切り替えるようにスレーブを要求します。これに先立ち、保護リンクが追加トラフィックを伝送している場合、マスターは（すなわち、トラフィックはマスターによって削除され、中に又は保護リンクの外に転送されません）このトラフィックのためのスパンを使用して停止します。
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.スレーブはマスタに確認応答を送信します。これに先立ち、スレーブは（すなわち、トラフィックはスレーブによって落下し、へたり保護リンクの外に転送されません）エキストラトラフィック用のリンクを使用して停止します。その後、選択した保護リンクで通常のトラフィックの送信を開始します。
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.は、新しいリンク上で通常のトラフィックを送受信を開始します。 LSPの切り替えが完了する。
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.
失敗表示メッセージ、LSP切替要求メッセージ、およびLSPスイッチオーバー応答メッセージ：1スパン保護それぞれ失敗したスパンのための3つのシグナリングメッセージまで必要とし得る。上記の説明から、1があることは明らかです。さらに、同時に保護スパンに現用スパンから複数のLSPを切り替えることも可能です。
The following functionality is required for dedicated 1:1 span protection:
1スパン保護：次の機能は、専用の1のために必要とされています。
o Pre-emption MUST be supported to accommodate Extra Traffic.
Oプリエンプションは、余分なトラフィックに対応するためにサポートしなければなりません。
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リンクは「1：1を専用の」リンク保護タイプと発表しています。余分なトラフィックが保護リンク上でサポートされている場合は、保護リンクの帯域幅パラメータも発表されなければなりません。作業および保護のリンクの帯域幅との間の区別は、優先順位のメカニズムを使用して行われます。言い換えれば、ネットワークは優先X以下で帯域幅が余分なトラフィックと見なされるように構成されなければなりません。
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.
作業リンクに障害が発生した場合には、通常のトラフィックは、必要に応じて追加のトラフィックを横取り、保護リンクに切り替えられます。保護リンクの帯域幅に応じて調整されなければなりません。
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シグナリング：作業リンクにリンク保護対象のLSPを確立する/ TLV「専用1：1」を示すそのLSPのためのシグナリング要求メッセージに含まれるべきです。保護リンクでLSPを確立するには、適切な優先順位は、（余分なトラフィックを示す）は、そのLSPのために使用されるべきです。これらのオブジェクト/のTLVは[RFC3471]で定義されています。リンク保護オブジェクト/ 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、故障指示メッセージは、リンク障害のノードに通知するマスターに送信されなければなりません。
Shared M:N protection is described with respect to two neighboring nodes, A and B. The scenario considered is as follows:
共有M：N保護は二つの隣接ノードに関して説明され、以下のように、Aと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（双方向）リンクの保護セットにトラフィック対象を運ぶN（双方向）リンクの集合が存在します。保護リンクは、余分なトラフィックを運ぶことができます。そこリンクの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、通常のトラフィックは、このようなリンクが利用可能な場合、保護セット内のリンクに転用されます。このようなリンクは、4つのSTS-48 LSPを担持する複数のLSP、例えば、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ワーキングセット内の複数のリンクが同じ障害イベントによって影響を受ける可能性があります。この場合、失敗した作業リンクによって運ば影響を受けるすべてのトラフィックに対応するために保護リンクの十分な数が存在しないことがあります。実際に利用可能な保護リンク上で復元され、影響を受けた作業リンクのセットは、（作業トラフィックの相対的な優先順位に基づいて、例えば、）の方針に従うものとします。これらのポリシーは、この文書で指定されていません。
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、保護リンクが選択されているためのよう決定は、常にノードのいずれかによって行われ、AまたはBこのノードは、「マスター」と考えられていますそして任意のポリシーを適用し、現用トラフィックをそらすために特定の保護リンクを選択するために、両方が必要です。他のノードが「スレーブ」と考えられています。マスタとスレーブの決意は、設定情報、プロトコル固有の要件、または近隣探索手順を実行した結果に基づくことができます。
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 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.
O失敗イベントは、利用可能な（例えば、SONETアラーム表示信号（AIS）/リモート障害表示（RDI））場合、トランスポート層機構によって検出されます。双方向リンクは、単方向リンクの対によって形成されているので、AからBへのリンクの障害は、典型的には、Bによって検出され、逆方向に障害がAで検出され、同時にへの障害の可能です双方向リンクの両方の方向に影響を与えます。この場合、AとBを同時に、それぞれ、Bツー方向および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.マスタが保護リンクのアイデンティティを決定したら、それはスレーブにこれを示し、（「切り替え要求」メッセージを使用して）、トラフィックの切り替えを要求します。これに先立ち、保護リンクが追加トラフィックを伝送している場合、マスターは（すなわち、トラフィックはマスターによって削除され、中に又は保護リンクの外に転送されません）このトラフィックのためのリンクを使用して停止します。
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.、それは以前に新しいリンクを介して、今、障害リンク上で実施されたトラフィックの送信と受信を開始します。
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.
障害表示メッセージ、スイッチオーバー要求メッセージ、および切り替え応答メッセージ：N（LSPローカル・リカバリを含む）スパン復元切り替えされている各作業リンクの最大3つのメッセージを必要とする場合があります。上記の説明から、Mがあることは明らかです。
The following functionality is required for M:N span restoration:
Nスパンの復元：次の機能は、Mのために必要とされています。
o Pre-emption MUST be supported to accommodate Extra Traffic.
Oプリエンプションは、余分なトラフィックに対応するためにサポートしなければなりません。
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リンクとリンクを保護するには、リンク保護タイプ「：N共有M」で発表される必要があります。余分なトラフィックが保護リンクのセット上でサポートされている場合は、保護リンクのセットのための帯域幅パラメータも発表されなければなりません。作業および保護のリンクの帯域幅との間の区別は、優先順位のメカニズムを使用して行われます。
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がある場合（複数可）、必要に応じて追加のトラフィックを横取り、保護リンクに切り替えなければなりません。保護リンクの帯域幅に応じて調整されなければなりません。
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シグナリングは：作業リンクでLSPを確立するには、リンク保護オブジェクト/ TLVを示す「共有Mは：N」そのLSPのためのシグナリング要求メッセージに含まれるべきです。保護リンクでLSPを確立するには、適切な優先順位は、（余分なトラフィックを示す）を使用してください。これらのオブジェクト/のTLVは[RFC3471]で定義されています。リンク保護オブジェクト/ 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]または手動構成を介しを用いて行うことができます。
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.
これらのメッセージは確実に送達されるべきです。したがって、これらのメッセージを配信するために使用されるプロトコルメカニズムは、配列決定、確認応答、および再送信を提供するべきです。プロトコルは、メッセージ（単数または複数）が配信できないような状況を処理します。
The messages described in the following subsections are abstract; their format and encoding will be described in separate documents.
以下のサブセクションで説明するメッセージは抽象的です。彼らのフォーマットとエンコーディングは別の文書で説明します。
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つまたは複数のリンクを働いて失敗したのアイデンティティを示すために、スレーブからマスタに送信されます。トランスポート・プレーン技術自体は、そのような通知を提供する場合、このメッセージは、必要ではないかもしれません。
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.
メッセージに含まれるリンクの数は、送信ノードによって、時間のウィンドウ内で検出された障害の数に依存します。ノードは、実装依存時間制約内の指定されたリンクの回復を完了するの利益のために別の障害表示メッセージを送信するために選ぶかもしれません。
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.
1と共有M：1専用下でNスパン保護、このメッセージは、LSP切替要求として使用されます。このメッセージは、（故障した）作業リンク上の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.
作業リンクは、複数のLSPを運ぶことができます。作業リンクを介して搬送される通常のトラフィックがプロテクションリンクに切り替えられるので、それぞれの個々のLSPを再シグナリングなしプロテクションリンクにマッピングされる作動リンク上のLSPのために可能です。 [RFC4201]を束ねるリンクが使用される場合、作用及び保護リンクがコンポーネントリンクにマッピングされ、そしてラベルは現用と予備リンクで同じであるれている場合、例えば、再することなく、コンポーネントのリンクを変更することも可能です各個々のLSPを知らせます。必要に応じて、ラベルは明示的に2つのノード間で協調する必要があるかもしれません。この場合、スイッチオーバー要求メッセージは、新しいラベルのマッピングを運ぶべきです。
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.
マスターは、すべてのリンクを作業失敗し対応するために、保護リンクを見つけることができない場合があります。このメッセージは、スレーブから失敗指示メッセージに応答して生成された場合したがって、そのメッセージに失敗したリンクのセットが失敗指示メッセージで受信されたリンクのサブ設定することができます。時間の制約によって、マスターは小さいバッチで失敗したリンクの集合から通常のトラフィックを切り換えることができます。従って、単一故障指示メッセージは、同一のスレーブノードに複数の切替要求メッセージを送信するマスタをもたらすことができます。
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 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.
このメッセージは、スレーブでの切り替えの完了（または失敗）を示すためにマスタ（確実）にスレーブから送信されます。このメッセージでは、スレーブは、それが何らかの理由で、対応するリンクフリーに切り替えることができないことを示してもよいです。この場合には、マスターとスレーブが失敗したスイッチオーバーのユーザ（オペレータ）に通知します。失敗の通知は、エンドツーエンドの回復におけるトリガーとして使用することができます。
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.
間違ったソースからのトラフィックが受信機に配信されたときに意図しない接続が発生します。これは、保護スイッチング中に防止しなければなりません。これは主に保護リンクが余分なトラフィックを運ぶために使用されている問題です。この場合、LSPトラフィックがプロテクションリンクに（失敗）作業リンクがプリエンプショントラフィックの受信機に配信されていないから切り替えられることが保証されなければなりません。したがって、上述したメッセージフローで、マスタノードは、切替要求を送信する前に選択されたプロテクションリンク上の（任意）プリエンプショントラフィックを切断しなければなりません。スレーブ・ノードは、切り替え応答を送信する前に横取りトラフィックを切断する必要があります。また、マスターノードは、保護リンクから保護されたLSPのトラフィックの受信を開始する必要があります。最後に、マスターノードは切り替え応答を受信すると、保護リンク上で保護されたトラフィックの送信を開始する必要があります。
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の主要経路が中間ノードのセットを介してターミネーター（ノードB）にイニシエータ（ノードA）から送られると仮定する。
The following subsections describe three previously proposed end-to-end protection schemes and the functional steps needed to implement them.
以下のサブセクションでは、3以前に提案されたエンド・ツー・エンドの保護スキームとそれらを実装するために必要な機能の手順を説明します。
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.
保護のこのモードに関わる明示的なシグナリングはありません。
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の切り替えの両方における現用パスの結果に影響を与える障害が発生。
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障害の検出：これには二つの可能性があります。
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.
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切り替え次のようにエンド・ノードは、ワーキングパスの障害を検出したときに取られるアクションは次のとおり予備パスから受信し始めます。同時に、他方の端部にスイッチング可能にするために他のエンドノードへの切り替え要求メッセージを送ります。
The action taken when an end node receives a Switchover Request message is as follows:
次のようにエンド・ノードは、切替要求メッセージを受信したときに取られるアクションです。
- Start receiving from the protection path; at the same time, send a Switchover Response message to the other end node.
- 保護パスから受信し始めます。同時に、他のエンドノードへの切り替え応答メッセージを送信します。
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シグナリングは、（確実に）失敗指示メッセージ、並びに切替要求および応答メッセージをシグナリングするために使用することができます。他のルーティングインテリジェンスがネットワークで利用可能でない場合、これらのメッセージは、プロテクションパスに沿って転送されてもよいです。
LSP Identifier: A unique identifier for each LSP. The LSP identifier is within the scope of the Source ID and Destination ID.
LSP識別子：各LSPの一意の識別子。 LSP識別子は、ソースIDとデスティネーションIDの範囲内です。
Source ID: ID of the source (e.g., IP address).
ソースID：ソースのID（例えば、IPアドレス）。
Destination ID: ID of the destination (e.g., IP address).
デスティネーションID：先のID（例えば、IPアドレス）。
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の現用または保護パス上にある各ノードは、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は、明示的にデプロビジョニングされるまで、関連する関連情報が維持されなければなりません。
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.
リンク障害を検出したノードを考えてみましょう。ノードは、リンクの障害によって影響を受けるすべてのLSPのアイデンティティを決定し、各LSPのソースにEnd-to-Endの障害指示メッセージを送信しなければなりません。スケーラビリティの理由により、障害表示メッセージは、アイデンティティと複数のLSPの状態ではなく、単一のものを含むかもしれません。そのようなメッセージを受信する各中間ノードは、メッセージが最終的にLSPのソースに到達するように、適切な次のノードにメッセージを転送しなければなりません。しかしながら、このメッセージは失敗したLSPと同じ経路に沿ってソースに向かって流れる必要はありません。中間ノードは、それ自体が障害指示メッセージを生成している場合はさらに、失敗指示メッセージのソースを除くすべてを抑制するための機構があるべきです。最後に、失敗指示メッセージは、LSP源に故障を検出したノードから確実に送らなければなりません。信頼性は、例えば、確認応答が受信されるまでメッセージを再送信することによって、達成することができます。しかし、障害表示メッセージの再送信は、さらにメッセージが低下する原因となるべきではありません。これは、適切なコンフィギュレーションおよび輻輳およびフロー制御メカニズムの使用を介して達成することができます。
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.
このメッセージは、エンドツーエンドの障害表示メッセージの受信を確認するために、ソースノードによって送信されます。このメッセージは、障害表示メッセージの発信者に送信されます。応答メッセージは、メッセージを受信した各障害表示のために送信されるべきです。障害の確認メッセージを受信する各中間ノードは、メッセージの宛先に向けて転送する必要があります。しかしながら、このメッセージは失敗したLSPと同じ経路に沿って目的地に向かって流れる必要はありません。
This message MAY not be required if other means of ensuring reliable message delivery are used.
信頼性の高いメッセージ配信を保証する他の手段が使用されている場合は、このメッセージは必要ないかもしれません。
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の識別子が復元されて搬送されます。エンドツーエンドの切替要求メッセージは、LSPのソースから宛先に確実に送らなければなりません。
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.
このメッセージは、LSPのソースに向かってエンドツーエンドの切替要求メッセージを受信し、宛先ノードによって送信されます。 LSPを識別すべきである。このメッセージは、切り替えされます。このメッセージは、受信された各エンドツーエンドの切り替え要求メッセージに応答して送信しなければならなくて、正または負の結果を示すことができます。
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.
共有メッシュ修復は、複数のLSPの保護パスが共通のリンクおよびノードリソースを共有する下のスキームを指します。これらのスキームの下で、保護容量が事前に予約され、すなわち、リンク容量は、一つまたは複数のLSPを保護するために割り当てられているが、明示的なアクションは、特定の保護LSPをインスタンス化するために必要とされます。これは、保護パスに沿って修復シグナリングを必要とします。典型的には、保護容量のみ、その現用パス物理的に多様であるLSPの間で共有されています。保護パスをプロビジョニングするときに、この基準は適用することができます。具体的には、プロビジョニング関連シグナリングメッセージは、プロテクションパスに沿ったノードの現用パスの情報を搬送することができます。これは、プライマリパスに使用されるリソースの識別に基づいて、プロテクションパスに沿って接続を拒否/承諾する呼受付制御として使用することができます。
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).
したがって、共有メッシュ修復は、単一障害イベント、すなわち、保護容量を共有する最大1つのLSPの現用パスに影響を与える障害が発生した後、LSPを保護するように設計されています。複数の同時障害イベントが発生したときに保護経路が正常に作動しない可能性があります。この場合、共有メッシュ修復能力は、複数の障害が発生したLSPのために記載されてもよく、予備パスのみ（最大で）それらのいずれかのために活性化することができます。
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.
セクション3.2.1および3.2.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リンクの総リソースを取る必要があります。
The End-to-End failure indication and acknowledgement procedures and messages are as defined in Sections 3.2.3 and 3.2.4.
End-to-Endの障害表示及び確認応答手順およびメッセージのように、セクション3.2.3および3.2.4に定義されています。
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 establishes cross-connects for the path. This would allow shared mesh restoration paths to be efficiently utilized.
このメッセージは、LSPに故障の指示を受信し、ソースノードによって生成されます。これは、保護パスに沿ってLSPの宛先に送信され、それはLSPが復元されて識別されます。任意の中間ノードはプロテクションパスのクロスコネクトを確立することができない場合、パス内の他のノードがパスにクロスコネクトを確立しないことが望ましいです。これは、共有メッシュ修復経路が効率的に利用することを可能にします。
The End-to-End Switchover message MUST be sent reliably from the source to the destination of the LSP along the protection path.
エンドツーエンドの切り替えメッセージが予備パスに沿ってLSPのソースから宛先に確実に送らなければなりません。
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.
このメッセージは、プロテクションパスに沿って、LSPのソースに向かってエンドツーエンドの切替要求メッセージを受信し、宛先ノードによって送信されます。このメッセージは、切り替えされているLSPを識別すべきです。経路に沿って各ホップで二次帯域を活性化する前に、余分なトラフィックが（使用する場合）を滴下し、転送されないことを意味します。
This message MUST be transmitted in response to each End-to-End Switchover Request message received.
このメッセージは、受信された各エンドツーエンドの切り替え要求メッセージに応答して送信されなければなりません。
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を移動するプロセスを指します。復帰は、ローカルSPANおよびエンドツーエンドのパス保護のLSPの両方に適用されます。復帰は、次のような理由から望まれています。まず、予備パスは、ビューのルーティングおよびリソース消費の点から現用パスと比較して最適ではないかもしれません。第二に、その現用パスにLSPを移動すると、保護リソースが他のLSPを保護するために使用することができます。復帰は、第2のサービスの中断を引き起こすという欠点を有します。復帰の使用は、オペレータの選択です。復帰は、現用パスがもともとさえ失敗した後、その上にルーティングされた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 selects the traffic from the working path. At the same time, it bridges the transmitted traffic onto both the working and protection paths.
2.ブリッジプロセスが完了すると、ソースノードは、ブリッジを送信し、宛先に要求メッセージを切り替え、復帰を実行するために必要なLSPと他の情報を識別する。このメッセージを受信すると、送信先は、現用パスからのトラフィックを選択します。同時に、それは作業と保護パスの両方に送信されたトラフィックをブリッジします。
3. The destination then sends a Bridge and Switch Response message to the source confirming the completion of the operation.
3.先は、橋を送信し、動作の完了を確認したソースに応答メッセージを切り替えます。
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が元に戻されたことを確認先にブリッジとスイッチ完了メッセージを送信します。
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を防止（保護またはその逆に作業から）スイッチオーバーを強制する能力を含みます。これらの管理の条件は、シグナリングによってサポートされる必要があります。
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.
スパンの保護の下では、障害イベントは、複数の作業をリンクに影響を与える可能性があり、失敗した作業リンクの数よりも少ない保護リンクがあるかもしれません。さらに、作業リンクは、優先順位の異なる複数のLSPを含有していてもよいです。このシナリオでは、意思決定は、への作業のリンク（そのためのLSP）として行われなければならない保護されなければなりません。この決定は、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.
一般的に、ノードは、順次、すべての失敗した作業リンクが同時に検出されない場合があり、即ち、逐次的障害を検出するが、可能性があります。この場合、提案されたシグナリング手順に従って、作業リンク上のLSPは、所与のプロテクションリンクに切り替えてもよいが、（より高い優先順位のLSPを運ぶ作業リンクの）別の障害は、すぐ後に検出することができます。この場合は、新しいLSPは、以前のものをぶつけて保護リンク上で切り替えます。
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
エンドツーエンドの共有メッシュ修復の場合、優先順位は、複数の障害シナリオの下で、共有リンクリソースを割り当てるために実装されてもよいです。複数のLSPは、3.3節で説明したように
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に割り当てなければならないかもしれません。
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（失敗指示メッセージ内の）データ・プレーン・エンドポイントのアイデンティティの保護は必要とされません
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.
不十分なセキュリティで保護された保護の結果は失敗の下にないLSP識別子を含む偽の障害表示メッセージ、下の回復アクションを誘発するリスクを高める可能性があります。そうする何の理由はありませんが、そのような情報は、その後、「偽」の回復動作の開始を引き起こす可能性があります。 LSPの識別が失敗指示メッセージから改ざんされた場合はさらに、回復アクションは、LSPを、任意の障害状態を示すものではありませんか、そのために何の障害表示メッセージを受信していないされたノードを含むことになります。そのような行動の結果は予測不可能であり、制御およびデータプレーン間の脱同期化につながるだけでなく、誤接続の危険性を増加させることができます。また、不十分な応用保護の結果は、誤接続のリスクを高める可能性があります。余分なトラフィックが関与しているとき、特に、誤った宛先に誤ったトラフィックを配信することが容易に可能です。同様に、有効な保護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.
また、ルーティング情報の交換を改ざんすることは、トラフィックエンジニアリング上の効果を有していてもよいです。したがって、ルーティング情報の送信を確保し、認証するために使用される任意の機構は、本文脈において適用されるべきです。
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保護と復旧のデザインチームで一緒に働いて多くの個人の産物でした。以下は、この文書に貢献著者です。
Deborah Brungard (AT&T) 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラBrungard（AT＆T）200 S.ローレルアベニューミドルタウン、NJ 07748、USA
EMail: dbrungard@att.com
メールアドレス：dbrungard@att.com
Sudheer Dharanikota
Sudhir 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東・デ・ラ・ゲラ・ストリートサンタバーバラ、CA 93101、USA
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
Guangzhiリー（AT＆T）180パークアベニュー、フローハムパーク、NJ 07932、USA
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
ディミトリスPapadimitriou（アルカテル）フランシスVellesplein、1 B-2018アントワープ、Velgiom
EMail: dimitri.papadimitriou@alcatel.be
メールアドレス：dimitri.papadimitriou@alcatel.be
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
バラRajagopalanマイクロソフト、インド開発センターハイデラバード、インド
EMail: balar@microsoft.com
メールアドレス：balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
ヤコフ・レックター（ジュニパー）1194 N.マチルダアベニューサニーベール、CA 94089、USA
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、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）"、RFC 4201、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、エド。、RFC 4203 "一般化マルチプロトコルラベルスイッチング（GMPLS）の支援でOSPF拡張機能"、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年10月。
[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、エド。、RFC 4205、2005年10月 "中間システム（IS-IS）一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで機能拡張への中間システム"。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、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）"、RFC 4427、2006年3月。
Editors' Addresses
エディタのアドレス
Jonathan P. Lang Sonos, Inc. 223 East De La Guerra Street Santa Barbara, CA 93101
ジョナサンP.ラングSonosの、株式会社223東・デ・ラ・ゲラ・ストリートサンタバーバラ、CA 93101
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
バラRajagopalanマイクロソフト、インド開発センターハイデラバード、インド
Ph: +91-40-5502-7423 EMail: balar@microsoft.com
Ph：+ 91-40-5502-7423 Eメール：balar@microsoft.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリスPapadimitriouアルカテルフランシスVellesplein、1 B-2018アントワープ、Velgiom
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 240-8491 Eメール：dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。