[要約] RFC 8227は、MPLS-TP Shared-Ring Protection (MSRP) メカニズムをリングトポロジーに適用するための仕様です。その目的は、MPLS-TPネットワークでリングトポロジーを保護するための効果的なメカニズムを提供することです。
Internet Engineering Task Force (IETF) W. Cheng
Request for Comments: 8227 L. Wang
Category: Standards Track H. Li
ISSN: 2070-1721 China Mobile
H. van Helvoort
Hai Gaoming BV
J. Dong
Huawei Technologies
August 2017
MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology
リングトポロジのMPLS-TP共有リング保護（MSRP）メカニズム
Abstract
概要
This document describes requirements, architecture, and solutions for MPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point-to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring.
このドキュメントでは、ポイントツーポイント（P2P）サービスのリングトポロジにおけるMPLS-TP共有リング保護（MSRP）の要件、アーキテクチャ、およびソリューションについて説明します。 MSRPメカニズムは、RFC 5654に記載されているリング保護要件を満たすように説明されています。このドキュメントでは、MPLSリング上のノードの保護動作を調整するために使用されるリング保護スイッチング（RPS）プロトコルを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8227.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8227で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
3. MPLS-TP Ring Protection Criteria and Requirements . . . . . . 5
4. Shared-Ring Protection Architecture . . . . . . . . . . . . . 6
4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Establishment of the Ring Tunnel . . . . . . . . . . 8
4.1.2. Label Assignment and Distribution . . . . . . . . . . 9
4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 9
4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 10
4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. Short-Wrapping . . . . . . . . . . . . . . . . . . . 14
4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Interconnected Ring Protection . . . . . . . . . . . . . 21
4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 21
4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 22
4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 23
4.4.4. Interconnected Ring-Switching Procedure . . . . . . . 25
4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 26
5. Ring Protection Coordination Protocol . . . . . . . . . . . . 27
5.1. RPS and PSC Comparison on Ring Topology . . . . . . . . . 27
5.2. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1. Transmission and Acceptance of RPS Requests . . . . . 30
5.2.2. RPS Protocol Data Unit (PDU) Format . . . . . . . . . 31
5.2.3. Ring Node RPS States . . . . . . . . . . . . . . . . 32
5.2.4. RPS State Transitions . . . . . . . . . . . . . . . . 34
5.3. RPS State Machine . . . . . . . . . . . . . . . . . . . . 36
5.3.1. Switch Initiation Criteria . . . . . . . . . . . . . 36
5.3.2. Initial States . . . . . . . . . . . . . . . . . . . 39
5.3.3. State Transitions When Local Request Is Applied . . . 40
5.3.4. State Transitions When Remote Request is Applied . . 44
5.3.5. State Transitions When Request Addresses to Another
Node is Received . . . . . . . . . . . . . . . . . . 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 51
6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 51
7. Operational Considerations . . . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . 53
9.2. Informative References . . . . . . . . . . . . . . . . . 54
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
As described in Section 2.5.6.1 of [RFC5654], several service providers have expressed much interest in operating an MPLS Transport Profile (MPLS-TP) in ring topologies and require a high-level survivability function in these topologies. In operational transport network deployment, MPLS-TP networks are often constructed using ring topologies. This calls for an efficient and optimized ring protection mechanism to achieve simple operation and fast, sub 50 ms, recovery performance.
[RFC5654]のセクション2.5.6.1で説明されているように、いくつかのサービスプロバイダーは、MPLSトランスポートプロファイル（MPLS-TP）をリングトポロジで運用することに大きな関心を示しており、これらのトポロジで高レベルの存続可能性機能を必要としています。運用トランスポートネットワークの展開では、MPLS-TPネットワークは、リングトポロジを使用して構築されることがよくあります。これには、効率的で最適化されたリング保護メカニズムが必要であり、シンプルな操作と高速の50ミリ秒未満のリカバリパフォーマンスを実現します。
This document specifies an MPLS-TP Shared-Ring Protection mechanism that meets the criteria for ring protection and the ring protection requirements described in Section 2.5.6.1 of [RFC5654].
このドキュメントでは、[RFC5654]のセクション2.5.6.1に記載されているリング保護の要件とリング保護要件を満たすMPLS-TP共有リング保護メカニズムを指定しています。
The basic concept and architecture of the MPLS-TP Shared-Ring Protection mechanism are specified in this document. This document describes the solutions for point-to-point transport paths. While the basic concept may also apply to point-to-multipoint transport paths, the solution for point-to-multipoint transport paths is out of the scope of this document.
このドキュメントでは、MPLS-TP共有リング保護メカニズムの基本概念とアーキテクチャについて説明します。このドキュメントでは、ポイントツーポイントのトランスポートパスのソリューションについて説明します。基本的な概念はポイントツーマルチポイントトランスポートパスにも適用できますが、ポイントツーマルチポイントトランスポートパスのソリューションはこのドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Terminology:
用語：
Ring node: All nodes in the ring topology are ring nodes, and they MUST actively participate in the ring protection.
リングノード：リングトポロジ内のすべてのノードはリングノードであり、それらはリング保護に積極的に参加する必要があります。
Ring tunnel: A ring tunnel provides a server layer for the Label Switched Paths (LSPs) traversing the ring. The notation used for a ring tunnel is: R<d><p><X> where <d> = c (clockwise) or a (anticlockwise), <p> = W (working) or P (protecting), and <X> = the node name.
リングトンネル：リングトンネルは、リングを通過するラベルスイッチドパス（LSP）のサーバーレイヤーを提供します。リングトンネルに使用される表記は次のとおりです。R<d> <p> <X>ここで、<d> = c（時計回り）またはa（反時計回り）、<p> = W（動作）またはP（保護）、および< X> =ノード名。
Ring map: A ring map is present in each ring node. The ring map contains the ring topology information, i.e., the nodes in the ring, the adjacency of the ring nodes, and the status of the links between ring nodes (Intact or Severed). The ring map is used by every ring node to determine the switchover behavior of the ring tunnels.
リングマップ：リングマップは各リングノードに存在します。リングマップには、リングトポロジ情報、つまりリング内のノード、リングノードの隣接関係、およびリングノード間のリンクのステータス（完全または切断）が含まれます。リングマップは、リングトンネルのスイッチオーバー動作を決定するために、すべてのリングノードによって使用されます。
Notation:
表記：
The following syntax will be used to describe the contents of the label stack:
次の構文は、ラベルスタックの内容を説明するために使用されます。
1. The label stack will be enclosed in square brackets ("[]").
1. ラベルスタックは角かっこ（ "[]"）で囲まれます。
2. Each level in the stack will be separated by the '|' character. It should be noted that the label stack may contain additional layers. However, we only present the layers that are related to the protection mechanism.
2. スタックの各レベルは「|」で区切られますキャラクター。ラベルスタックには追加のレイヤーが含まれる場合があることに注意してください。ただし、保護メカニズムに関連するレイヤーのみを示します。
3. If the label is assigned by Node X, the Node Name is enclosed in parentheses ("()").
3. ラベルがノードXによって割り当てられる場合、ノード名は括弧（ "()"）で囲まれます。
The generic requirements for MPLS-TP protection are specified in [RFC5654]. The requirements specific for ring protection are specified in Section 2.5.6.1 of [RFC5654]. This section describes how the criteria for ring protection are met:
MPLS-TP保護の一般的な要件は、[RFC5654]で指定されています。リング保護に固有の要件は、[RFC5654]のセクション2.5.6.1で指定されています。このセクションでは、リング保護の基準がどのように満たされるかについて説明します。
a. The number of Operations, Administration, and Maintenance (OAM) entities needed to trigger protection
a. 保護をトリガーするために必要な運用、管理、および保守（OAM）エンティティの数
Each ring node requires only one instance of the RPS protocol per ring. The OAM of the links connected to the adjacent ring nodes has to be forwarded to only this instance in order to trigger protection. For detailed information, see Section 5.2.
各リングノードには、リングごとにRPSプロトコルのインスタンスが1つだけ必要です。隣接するリングノードに接続されているリンクのOAMは、保護をトリガーするために、このインスタンスのみに転送する必要があります。詳細については、セクション5.2を参照してください。
b. The number of elements of recovery in the ring
b. リング内の回復の要素の数
Each ring node requires only one instance of the RPS protocol and is independent of the number of LSPs that are protected. For detailed information, see Section 5.2.
各リングノードはRPSプロトコルのインスタンスを1つだけ必要とし、保護されているLSPの数とは無関係です。詳細については、セクション5.2を参照してください。
c. The required number of labels required for the protection paths
c. 保護パスに必要なラベルの必要数
The RPS protocol uses ring tunnels, and each tunnel has a set of labels. The number of ring tunnel labels is related to the number of ring nodes and is independent of the number of protected LSPs. For detailed information, see Section 4.1.2.
RPSプロトコルはリングトンネルを使用し、各トンネルには一連のラベルがあります。リングトンネルラベルの数は、リングノードの数に関連し、保護されたLSPの数とは無関係です。詳細については、セクション4.1.2を参照してください。
d. The amount of control and management-plane transactions
d. 制御および管理プレーントランザクションの量
Each ring node requires only one instance of the RPS protocol per ring. This means that only one maintenance operation is required per ring node. For detailed information, see Section 5.2.
各リングノードには、リングごとにRPSプロトコルのインスタンスが1つだけ必要です。つまり、リングノードごとに必要なメンテナンス操作は1つだけです。詳細については、セクション5.2を参照してください。
e. Minimize the signaling and routing information exchange during protection
e. 保護中のシグナリングおよびルーティング情報交換を最小限に抑える
Information exchange during a protection switch is using the in-band RPS and OAM messages. No control-plane interactions are required. For detailed information, see Section 5.2.
保護切り替え中の情報交換は、インバンドRPSおよびOAMメッセージを使用しています。コントロールプレーンの相互作用は必要ありません。詳細については、セクション5.2を参照してください。
This document introduces a new logical layer of the ring for shared-ring protection in MPLS-TP networks. As shown in Figure 1, the new logical layer consists of ring tunnels that provide a server layer for the LSPs traversing the ring. Once a ring tunnel is established, the forwarding and protection switching of the ring are all performed at the ring tunnel level. A port can carry multiple ring tunnels, and a ring tunnel can carry multiple LSPs.
このドキュメントでは、MPLS-TPネットワークでの共有リング保護のためのリングの新しい論理層を紹介します。図1に示すように、新しい論理層はリングトンネルで構成され、リングを通過するLSPにサーバー層を提供します。リングトンネルが確立されると、リングの転送と保護切り替えはすべてリングトンネルレベルで実行されます。ポートは複数のリングトンネルを伝送でき、リングトンネルは複数のLSPを伝送できます。
+-------------
+-------------|
+-------------| |
===Service1===| | |
===Service2===| LSP1 | |
+-------------| |
|Ring-Tunnel1 |
+-------------| |
===Service3===| | |
===Service4===| LSP2 | |
+-------------| |
+-------------| Physical
+-------------|
+-------------| | Port
===Service5===| | |
===Service6===| LSP3 | |
+-------------| |
|Ring-Tunnel2 |
+-------------| |
===Service7===| | |
===Service8===| LSP4 | |
+-------------| |
+-------------|
+-------------
Figure 1: The Logical Layers of the Ring
図1：リングの論理層
The label stack used in the MPLS-TP Shared-Ring Protection mechanism is [Ring Tunnel Label|LSP Label|Service Label](Payload) as illustrated in Figure 2.
図2に示すように、MPLS-TP共有リング保護メカニズムで使用されるラベルスタックは、[リングトンネルラベル| LSPラベル|サービスラベル]（ペイロード）です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring Tunnel Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Label Stack Used in MPLS-TP Shared-Ring Protection
図2：MPLS-TP共有リング保護で使用されるラベルスタック
The Ring tunnels are established based on the egress nodes. The egress node is the node where traffic leaves the ring. LSPs that have the same egress node on the ring and travel along the ring in the same direction (clockwise or anticlockwise) share the same ring tunnels. In other words, all the LSPs that traverse the ring in the same direction and exit from the same node share the same working ring tunnel and protection ring tunnel. For each egress node, four ring tunnels are established:
リングトンネルは、出力ノードに基づいて確立されます。出力ノードは、トラフィックがリングを出るノードです。リングに同じ出口ノードがあり、リングに沿って同じ方向（時計回りまたは反時計回り）に移動するLSPは、同じリングトンネルを共有します。つまり、リングを同じ方向に通過し、同じノードから出るすべてのLSPは、同じ現用リングトンネルと保護リングトンネルを共有します。出力ノードごとに、4つのリングトンネルが確立されます。
o one clockwise working ring tunnel, which is protected by the anticlockwise protection ring tunnel
o 反時計回りの保護リングトンネルによって保護されている1つの時計回りの作業リングトンネル
o one anticlockwise protection ring tunnel
o 1つの反時計回りの保護リングトンネル
o one anticlockwise working ring tunnel, which is protected by the clockwise protection ring tunnel
o 時計回りの保護リングトンネルによって保護されている反時計回りの作業リングトンネル
o one clockwise protection ring tunnel
o 1つの時計回りの保護リングトンネル
The structure of the protection tunnels is determined by the selected protection mechanism. This will be detailed in subsequent sections.
保護トンネルの構造は、選択した保護メカニズムによって決まります。これについては、後続のセクションで詳しく説明します。
As shown in Figure 3, LSP1, LSP2, and LSP3 enter the ring from Node E, Node A, and Node B, respectively, and all leave the ring at Node D. To protect these LSPs that traverse the ring, a clockwise working ring tunnel (RcW_D) via E->F->A->B->C->D and its anticlockwise protection ring tunnel (RaP_D) via D->C->B->A->F->E->D are established. Also, an anticlockwise working ring tunnel (RaW_D) via C->B->A->F->E->D and its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D are established. For simplicity, Figure 3 only shows RcW_D and RaP_D. A similar provisioning should be applied for any other node on the ring. In summary, for each node in Figure 3, when acting as an egress node, the ring tunnels are created as follows:
図3に示すように、LSP1、LSP2、およびLSP3はそれぞれノードE、ノードA、およびノードBからリングに入り、リングはすべてノードDでリングを離れます。リングを通過するこれらのLSPを保護するには、時計回りに機能するリングE-> F-> A-> B-> C-> Dを介したトンネル（RcW_D）およびD-> C-> B-> A-> F-> E-> Dを介したその反時計回りの保護リングトンネル（RaP_D）確立されます。また、C-> B-> A-> F-> E-> Dを介した反時計回りの動作リングトンネル（RaW_D）およびD-> E-> F-> A-> Bを介した時計回りの保護リングトンネル（RcP_D） -> C-> Dが確立されます。簡単にするために、図3ではRcW_DとRaP_Dのみを示しています。リング上の他のノードにも同様のプロビジョニングを適用する必要があります。要約すると、図3の各ノードについて、出口ノードとして機能する場合、リングトンネルは次のように作成されます。
o To Node A: RcW_A, RaW_A, RcP_A, RaP_A
o ノードAへ：RcW_A、RaW_A、RcP_A、RaP_A
o To Node B: RcW_B, RaW_B, RcP_B, RaP_B
o ノードBへ：RcW_B、RaW_B、RcP_B、RaP_B
o To Node C: RcW_C, RaW_C, RcP_C, RaP_C
o ノードCへ：RcW_C、RaW_C、RcP_C、RaP_C
o To Node D: RcW_D, RaW_D, RcP_D, RaP_D
o ノードDへ：RcW_D、RaW_D、RcP_D、RaP_D
o To Node E: RcW_E, RaW_E, RcP_E, RaP_E
o と ので え： ＲｃＷ＿え、 らＷ＿え、 ＲｃＰ＿え、 らＰ＿え
o To Node F: RcW_F, RaW_F, RcP_F, RaP_F
o ノードFへ：RcW_F、RaW_F、RcP_F、RaP_F
+---+#############+---+
| F |-------------| A | +-- LSP2
+---+*************+---+
#/* *\#
#/* *\#
#/* *\#
+---+ +---+
LSP1 --+ | E | | B |+-- LSP3
+---+ +---+
#\ */#
#\ */#
#\ */#
+---+*************+---+
LSP1 +--| D |-------------| C |
LSP2 +---+#############+---+
LSP3
----- Physical Links
***** RcW_D
##### RaP_D
Figure 3: Ring Tunnels in MSRP
図3：MSRPのリングトンネル
Through these working and protection ring tunnels, LSPs that enter the ring from any node can reach any egress nodes on the ring and are protected from failures on the ring.
これらの現用および保護リングトンネルを介して、任意のノードからリングに入るLSPは、リング上の任意の出力ノードに到達でき、リング上の障害から保護されます。
The ring tunnel labels are downstream-assigned labels as defined in [RFC3031]. The ring tunnel labels on each hop of the ring tunnel can be either configured statically, provisioned by a controller, or distributed dynamically via a control protocol. For an LSP that traverses the ring tunnel, the ingress ring node and the egress ring node are considered adjacent at the LSP layer, and LSP label needs to be allocated at these two ring nodes. The control plane for label distribution is outside the scope of this document.
リングトンネルラベルは、[RFC3031]で定義されているように、ダウンストリームに割り当てられたラベルです。リングトンネルの各ホップのリングトンネルラベルは、静的に構成するか、コントローラーによってプロビジョニングするか、または制御プロトコルを介して動的に配布できます。リングトンネルを通過するLSPの場合、入力リングノードと出力リングノードはLSPレイヤーで隣接していると見なされ、LSPラベルはこれらの2つのリングノードに割り当てる必要があります。ラベル配布のコントロールプレーンは、このドキュメントの範囲外です。
When an MPLS-TP transport path, i.e., an LSP, enters the ring, the ingress node on the ring pushes the working ring tunnel label that is used to reach the specific egress node and sends the traffic to the next hop. The transit nodes on the working ring tunnel swap the ring tunnel labels and forward the packets to the next hop. When the packet arrives at the egress node, the egress node pops the ring tunnel label and forwards the packets based on the inner LSP label and service label. Figure 4 shows the label operation in the MPLS-TP Shared-Ring Protection mechanism. Assume that LSP1 enters the ring at Node A and exits from Node D, and the following label operations are executed.
MPLS-TPトランスポートパス、つまりLSPがリングに入ると、リング上の入力ノードは、特定の出力ノードに到達するために使用される現用リングトンネルラベルをプッシュし、トラフィックをネクストホップに送信します。現用リングトンネルのトランジットノードは、リングトンネルラベルを交換し、パケットをネクストホップに転送します。パケットが出力ノードに到着すると、出力ノードはリングトンネルラベルをポップし、内部LSPラベルとサービスラベルに基づいてパケットを転送します。図4は、MPLS-TP共有リング保護メカニズムでのラベル操作を示しています。 LSP1がノードAでリングに入り、ノードDから出て、次のラベル操作が実行されると仮定します。
1. Ingress node: Packets of LSP1 arrive at Node A with a label stack [LSP1] and are supposed to be forwarded in the clockwise direction of the ring. The label of the clockwise working ring tunnel RcW_D will be pushed at Node A, the label stack for the forwarded packet at Node A is changed to [RcW_D(B)|LSP1].
1. 入力ノード：LSP1のパケットはラベルスタック[LSP1]でノードAに到着し、リングの時計回りの方向に転送されることになっています。時計回りの現用リングトンネルRcW_DのラベルはノードAでプッシュされ、ノードAで転送されたパケットのラベルスタックは[RcW_D（B）| LSP1]に変更されます。
2. Transit nodes: In this case, Nodes B and C forward the packets by swapping the working ring tunnel labels. For example, the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node B.
2. トランジットノード：この場合、ノードBとCは、現用のリングトンネルラベルを交換してパケットを転送します。たとえば、ラベル[RcW_D（B）| LSP1]はノードBで[RcW_D（C）| LSP1]にスワップされます。
3. Egress node: When the packet arrives at Node D (i.e., the egress node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D) and subsequently deals with the inner labels of LSP1.
3. 出口ノード：パケットがラベルスタック[RcW_D（D）| LSP1]でノードD（つまり、出口ノード）に到着すると、ノードDはRcW_D（D）をポップし、LSP1の内部ラベルを処理します。
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)]
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ */#
[RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)]
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
----- Physical Links
***** RcW_D
##### RaP_D
Figure 4: Label Operation of MSRP
図4：MSRPのラベル操作
The MPLS-TP section-layer OAM is used to monitor the connectivity between each two adjacent nodes on the ring using the mechanisms defined in [RFC6371]. Protection switching is triggered by the failure detected on the ring by the OAM mechanisms.
MPLS-TPセクション層OAMは、[RFC6371]で定義されたメカニズムを使用して、リング上の各2つの隣接ノード間の接続を監視するために使用されます。保護切り替えは、OAMメカニズムによってリングで検出された障害によってトリガーされます。
Two ports of a link form a Maintenance Entity Group (MEG), and a MEG End Point (MEP) function is installed in each ring port. Continuity Check (CC) OAM packets are periodically exchanged between each pair of MEPs to monitor the link health. Three consecutive lost CC packets MUST be interpreted as a link failure.
リンクの2つのポートは保守エンティティグループ（MEG）を形成し、MEGエンドポイント（MEP）機能は各リングポートにインストールされます。 Continuity Check（CC）OAMパケットは、リンクの状態を監視するために、MEPの各ペア間で定期的に交換されます。 3つの連続した失われたCCパケットは、リンク障害として解釈される必要があります。
A node failure is regarded as the failure of two links attached to that node. The two nodes adjacent to the failed node detect the failure in the links that are connected to the failed node.
ノード障害は、そのノードに接続された2つのリンクの障害と見なされます。障害が発生したノードに隣接する2つのノードは、障害が発生したノードに接続されているリンクの障害を検出します。
This section specifies the ring protection mechanisms in detail. In general, the description uses the clockwise working ring tunnel and the corresponding anticlockwise protection ring tunnel as an example, but the mechanism is applicable in the same way to the anticlockwise working and clockwise protection ring tunnels.
このセクションでは、リング保護メカニズムを詳細に指定します。一般に、説明では時計回りのワーキングリングトンネルと対応する反時計回りの保護リングトンネルを例として使用しますが、メカニズムは反時計回りの作業リングトンネルと時計回りの保護リングトンネルにも同じように適用できます。
In a ring network, each working ring tunnel is associated with a protection ring tunnel in the opposite direction, and every node MUST obtain the ring topology either by configuration or via a topology discovery mechanism. The ring topology and the connectivity (Intact or Severed) between two adjacent ring nodes form the ring map. Each ring node maintains the ring map and uses it to perform ring protection switching.
リングネットワークでは、各動作中のリングトンネルは反対方向の保護リングトンネルに関連付けられており、すべてのノードは、構成またはトポロジー検出メカニズムを介してリングトポロジーを取得する必要があります。リングトポロジと2つの隣接するリングノード間の接続性（インタクトまたは切断）がリングマップを形成します。各リングノードはリングマップを保持し、それを使用してリング保護切り替えを実行します。
Taking the topology in Figure 4 as an example, LSP1 enters the ring at Node A and leaves the ring at Node D. In normal state, LSP1 is carried by the clockwise working ring tunnel (RcW_D) through the path A->B->C->D. The label operation is:
図4のトポロジを例にとると、LSP1はノードAでリングに入り、ノードDでリングを離れます。通常の状態では、LSP1はパスA-> B->を介して時計回りの動作リングトンネル（RcW_D）によって伝送されます。 C-> D。ラベル操作は次のとおりです。
[LSP1](Payload) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload).
「ＬＳＰ１」（ぱｙぉあｄ） ー＞ 「ＲＣＷ＿Ｄ（Ｂ）｜ＬＳＰ１」（のであ） ー＞ 「ＲＣＷ＿Ｄ（Ｃ）｜ＬＳＰ１」（のでＢ） ー＞ 「ＲＣＷ＿Ｄ（Ｄ）｜ ＬＳＰ１」（のでＣ） ー＞ 「ＬＳＰ１」（ぱｙぉあｄ）。
Then at Node D, the packet will be forwarded based on the label stack of LSP1.
次に、ノードDでは、パケットはLSP1のラベルスタックに基づいて転送されます。
Three typical ring protection mechanisms are described in this section: wrapping, short-wrapping, and steering. All nodes on the same ring MUST use the same protection mechanism. If the RPS protocol in any node detects an RPS message with a protection-switching mode that was not provisioned in that node, a failure of protocol will be reported, and the protection mechanism will not be activated.
このセクションでは、3つの典型的なリング保護メカニズム（ラッピング、ショートラッピング、ステアリング）について説明します。同じリング上のすべてのノードは、同じ保護メカニズムを使用する必要があります。いずれかのノードのRPSプロトコルが、そのノードでプロビジョニングされていない保護切り替えモードのRPSメッセージを検出した場合、プロトコルの障害が報告され、保護メカニズムはアクティブ化されません。
Wrapping ring protection: the node that detects a failure or accepts a switch request switches the traffic impacted by the failure or the switch request to the opposite direction (away from the failure). In this way, the impacted traffic is switched to the protection ring tunnel by the switching node upstream of the failure, then it travels around the ring to the switching node downstream of the failure through the protection ring tunnel, where it is switched back onto the working ring tunnel to reach the egress node.
ラッピングリング保護：障害を検出するか、切り替え要求を受け入れるノードは、障害または切り替え要求の影響を受けるトラフィックを反対方向（障害から離れる方向）に切り替えます。このようにして、影響を受けたトラフィックは、障害の上流にあるスイッチングノードによって保護リングトンネルに切り替えられ、保護リングトンネルを介してリングの周りを流れ、障害の下流にあるスイッチングノードに移動します。出力ノードに到達するためのリングトンネルの動作。
Short-wrapping ring protection provides some optimization to wrapping protection, in which the impacted traffic is only switched once to the protection ring tunnel by the switching node upstream to the failure. At the egress node, the traffic leaves the ring from the protection ring tunnel. This can reduce the traffic detour of wrapping protection.
ショートラッピングリング保護は、ラッピング保護にある程度の最適化を提供します。この場合、影響を受けるトラフィックは、障害の上流にあるスイッチングノードによって、保護リングトンネルに一度だけ切り替えられます。出力ノードでは、トラフィックは保護リングトンネルからリングを離れます。これにより、ラッピング保護の迂回トラフィックを減らすことができます。
Steering ring protection implies that the node that detects a failure sends a request along the ring to the other node adjacent to the failure, and all nodes in the ring process this information. For the impacted traffic, the ingress node (which adds traffic to the ring) performs switching of the traffic from working to the protection ring tunnel, and the egress node will drop the traffic received from the protection ring tunnel.
ステアリングリング保護は、障害を検出したノードがリングに沿って障害に隣接する他のノードに要求を送信し、リング内のすべてのノードがこの情報を処理することを意味します。影響を受けるトラフィックの場合、（リングにトラフィックを追加する）入力ノードがトラフィックの動作を保護リングトンネルに切り替え、出力ノードは保護リングトンネルから受信したトラフィックをドロップします。
The following sections describe these protection mechanisms in detail.
次のセクションでは、これらの保護メカニズムについて詳しく説明します。
With the wrapping mechanism, the protection ring tunnel is a closed ring identified by the egress node. As shown in Figure 4, the RaP_D is the anticlockwise protection ring tunnel for the clockwise working ring tunnel RcW_D. As specified in the following sections, the closed ring protection tunnel can protect both link failures and node failures. Wrapping can be applicable for the protection of Point-to-Multipoint (P2MP) LSPs on the ring; the details of which are outside the scope of this document.
ラッピングメカニズムでは、保護リングトンネルは、出口ノードによって識別される閉じたリングです。図4に示すように、RaP_Dは時計回りの現用リングトンネルRcW_Dの反時計回りの保護リングトンネルです。次のセクションで指定するように、クローズドリング保護トンネルは、リンク障害とノード障害の両方を保護できます。ラップは、リング上のポイントツーマルチポイント（P2MP）LSPの保護に適用できます。詳細はこのドキュメントの範囲外です。
When a link failure between Nodes B and C occurs, if it is a bidirectional failure, both Nodes B and C can detect the failure via the OAM mechanism; if it is a unidirectional failure, one of the two nodes would detect the failure via the OAM mechanism. In both cases, the node at the other side of the detected failure will be determined by the ring map and informed using the RPS protocol, which is specified in Section 5. Then Node B switches the clockwise working ring tunnel (RcW_D) to the anticlockwise protection ring tunnel (RaP_D), and Node C switches the anticlockwise protection ring tunnel (RaP_D) back to the clockwise working ring tunnel (RcW_D). The payload that enters the ring at Node A and leaves the ring at Node D follows the path A->B->A->F->E->D->C->D. The label operation is:
ノードBとノードCの間でリンク障害が発生した場合、それが双方向障害であれば、ノードBとノードCの両方がOAMメカニズムを介して障害を検出できます。単一方向の障害の場合、2つのノードの1つがOAMメカニズムを介して障害を検出します。どちらの場合も、検出された障害の反対側のノードは、リングマップによって決定され、セクション5で指定されているRPSプロトコルを使用して通知されます。次に、ノードBは時計回りの動作リングトンネル（RcW_D）を反時計回りに切り替えます保護リングトンネル（RaP_D）、およびノードCは、反時計回りの保護リングトンネル（RaP_D）を時計回りの現用リングトンネル（RcW_D）に切り替えます。ノードAでリングに入り、ノードDでリングから出るペイロードは、パスA-> B-> A-> F-> E-> D-> C-> Dをたどります。ラベル操作は次のとおりです。
[LSP1](Payload) -> [RcW_D(B)|LSP1](Node A) -> [RaP_D(A)|LSP1](Node B)
-> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] (Node F) ->
[RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) ->
[RcW_D(D)|LSP1](Node C) -> [LSP1](Payload).
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
----- Physical Links xxxxx Failure Links
***** RcW_D ##### RaP_D
Figure 5: Wrapping for Link Failure
図5：リンク障害の折り返し
As shown in Figure 6, when Node B fails, Node A detects the failure between A and B and switches the clockwise working ring tunnel (RcW_D) to the anticlockwise protection ring tunnel (RaP_D); Node C detects the failure between C and B and switches the anticlockwise protection ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D). The node at the other side of the failed node will be determined by the ring map and informed using the RPS protocol specified in Section 5.
図6に示すように、ノードBに障害が発生すると、ノードAはAとBの間の障害を検出し、時計回りの現用リングトンネル（RcW_D）を反時計回りの保護リングトンネル（RaP_D）に切り替えます。ノードCはCとBの間の障害を検出し、反時計回りの保護リングトンネル（RaP_D）を時計回りの動作リングトンネル（RcW_D）に切り替えます。障害が発生したノードの反対側のノードは、リングマップによって決定され、セクション5で指定されたRPSプロトコルを使用して通知されます。
The payload that enters the ring at Node A and exits at Node D follows the path A->F->E->D->C->D. The label operation is:
ノードAでリングに入りノードDで出るペイロードは、パスA-> F-> E-> D-> C-> Dをたどります。ラベル操作は次のとおりです。
[LSP1](Payload)-> [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] (NodeC) -> [LSP1](Payload).
[LSP1](Payload)-> [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] (NodeC) -> [LSP1](Payload).
In one special case where Node D fails, all the ring tunnels with Node D as the egress will become unusable. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable; thus, it will not send traffic to either the working or the protection tunnel. However, before the failure location information is propagated to all the ring nodes, the wrapping protection mechanism may cause a temporary traffic loop: Node C detects the failure and switches the traffic from the clockwise working ring tunnel (RcW_D) to the anticlockwise protection ring tunnel (RaP_D); Node E also detects the failure and switches the traffic from the anticlockwise protection ring tunnel (RaP_D) back to the clockwise working ring tunnel (RcW_D). A possible mechanism to mitigate the temporary loop problem is: the TTL of the ring tunnel label is set to 2*N by the ingress ring node of the traffic, where N is the number of nodes on the ring.
ノードDに障害が発生した特殊なケースの1つとして、ノードDとの出口としてのすべてのリングトンネルが使用できなくなります。入力ノードは、受信したRPSメッセージに従ってリングマップを更新し、出力ノードに到達できないと判断します。したがって、トラフィックは現用トンネルと保護トンネルのどちらにも送信されません。ただし、障害位置情報がすべてのリングノードに伝達される前に、ラッピング保護メカニズムにより一時的なトラフィックループが発生する可能性があります。ノードCが障害を検出し、トラフィックを時計回りの現用リングトンネル（RcW_D）から反時計回りの保護リングトンネルに切り替えます。 （RaP_D）;ノードEも障害を検出し、トラフィックを反時計回りの保護リングトンネル（RaP_D）から時計回りの動作リングトンネル（RcW_D）に切り替えます。一時的なループの問題を軽減するための可能なメカニズムは、次のとおりです。リングトンネルラベルのTTLは、トラフィックの入力リングノードによって2 * Nに設定されます。ここで、Nはリング上のノードの数です。
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ xxxxx
| E | x B x
+---+ xxxxx
#\ */#
[RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B)
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
----- Physical Links xxxxx Failure Nodes
***** RcW_D ##### RaP_D
Figure 6: Wrapping for Node Failure
図6：ノード障害の折り返し
With the wrapping protection scheme, protection switching is executed at both nodes adjacent to the failure; consequently, the traffic will be wrapped twice. This mechanism will cause additional latency and bandwidth consumption when traffic is switched to the protection path.
ラッピング保護スキームでは、障害に隣接する両方のノードで保護切り替えが実行されます。その結果、トラフィックは2回ラップされます。このメカニズムにより、トラフィックが保護パスに切り替えられるときに、レイテンシと帯域幅の消費が増加します。
With short-wrapping protection, protection switching is executed only at the node upstream to the failure, and the packet leaves the ring in the protection ring tunnel at the egress node. This scheme can reduce the additional latency and bandwidth consumption when traffic is switched to the protection path. However, the two directions of a protected bidirectional LSP are no longer co-routed under the protection-switching conditions.
ショートラップ保護では、保護切り替えは障害の上流のノードでのみ実行され、パケットは出力ノードの保護リングトンネルのリングを離れます。このスキームにより、トラフィックが保護パスに切り替えられたときに、追加のレイテンシと帯域幅の消費を削減できます。ただし、保護切り替えの条件下では、保護された双方向LSPの2つの方向は同じ方向にルーティングされなくなります。
In the traditional wrapping solution, the protection ring tunnel is configured as a closed ring, while in the short-wrapping solution, the protection ring tunnel is configured as ended at the egress node, which is similar to the working ring tunnel. Short-wrapping is easy to implement in shared-ring protection because both the working and protection ring tunnels are terminated on the egress nodes. Figure 7 shows the clockwise working ring tunnel and the anticlockwise protection ring tunnel with Node D as the egress node.
従来のラッピングソリューションでは、保護リングトンネルはクローズドリングとして構成されますが、短いラッピングソリューションでは、保護リングトンネルは、現用リングトンネルと同様に、出口ノードで終了するように構成されます。ワーキングリングトンネルとプロテクションリングトンネルの両方が出口ノードで終端されているため、ショートラップは共有リング保護に簡単に実装できます。図7は、ノードDを出力ノードとして使用した、時計回りの現用リングトンネルと反時計回りの保護リングトンネルを示しています。
As shown in Figure 7, in normal state, LSP1 is carried by the clockwise working ring tunnel (RcW_D) through the path A->B->C->D. When a link failure between Nodes B and C occurs, Node B switches the working ring tunnel RcW_D to the protection ring tunnel RaP_D in the opposite direction. The difference with wrapping occurs in the protection ring tunnel at the egress node. In short-wrapping protection, Rap_D ends in Node D, and then traffic will be forwarded based on the LSP labels. Thus, with the short-wrapping mechanism, LSP1 will follow the path A->B->A->F->E->D when a link failure between Node B and Node C happens. The protection switch at Node D is based on the information from its ring map and the information received via the RPS protocol.
図7に示すように、通常の状態では、LSP1は時計回りのワーキングリングトンネル（RcW_D）によってパスA-> B-> C-> Dを介して伝送されます。ノードBとノードCの間のリンク障害が発生すると、ノードBは現用リングトンネルRcW_Dを保護リングトンネルRaP_Dに逆方向に切り替えます。ラッピングとの違いは、出力ノードの保護リングトンネルで発生します。ショートラップ保護では、Rap_DはノードDで終了し、LSPラベルに基づいてトラフィックが転送されます。したがって、ショートラッピングメカニズムでは、ノードBとノードCの間のリンク障害が発生すると、LSP1はパスA-> B-> A-> F-> E-> Dをたどります。ノードDの保護切り替えは、そのリングマップからの情報とRPSプロトコルを介して受信した情報に基づいています。
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+ +---+
----- Physical Links xxxxx Failure Links
***** RcW_D ##### RaP_D
Figure 7: Short-Wrapping for Link Failure
図7：リンク障害のショートラップ
For the node failure that happens on a non-egress node, the short-wrapping protection switching is similar to the link failure case as described in the previous section. This section specifies the scenario of an egress node failure.
非出力ノードで発生するノード障害の場合、ショートラップ保護スイッチングは、前のセクションで説明したリンク障害の場合と同様です。このセクションでは、出力ノードの障害のシナリオを指定します。
As shown in Figure 8, LSP1 enters the ring on Node A and leaves the ring on Node D. In normal state, LSP1 is carried by the clockwise working ring tunnel (RcW_D) through the path A->B->C->D. When Node D fails, the traffic of LSP1 cannot be protected by any ring tunnels that use Node D as the egress node. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable; thus, it will not send traffic to either the working or the protection tunnel. However, before the failure location information is propagated to all the ring nodes using the RPS protocol, Node C switches all the traffic on the working ring tunnel RcW_D to the protection ring tunnel RaP_D in the opposite direction based on the information in the ring map. When the traffic arrives at Node E, which also detects the failure of Node D, the protection ring tunnel RaP_D cannot be used to forward traffic to Node D. With the short-wrapping mechanism, protection switching can only be performed once from the working ring tunnel to the protection ring tunnel; thus, Node E MUST NOT switch the traffic that is already carried on the protection ring tunnel back to the working ring tunnel in the opposite direction. Instead, Node E will discard the traffic received on RaP_D locally. This can avoid the temporary traffic loop when the failure happens on the egress node of the ring tunnel. This also illustrates one of the benefits of having separate working and protection ring tunnels in each ring direction.
図8に示すように、LSP1はノードAのリングに入り、ノードDのリングを離れます。通常の状態では、LSP1は時計回りに動作するリングトンネル（RcW_D）によってパスA-> B-> C-> Dを経由して運ばれます。 。ノードDに障害が発生すると、LSP1のトラフィックは、ノードDを出力ノードとして使用するリングトンネルによって保護できません。入力ノードは、受信したRPSメッセージに従ってリングマップを更新し、出力ノードに到達できないと判断します。したがって、トラフィックは現用トンネルと保護トンネルのどちらにも送信されません。ただし、障害位置情報がRPSプロトコルを使用してすべてのリングノードに伝達される前に、ノードCは、リングマップの情報に基づいて、現用リングトンネルRcW_D上のすべてのトラフィックを反対方向に保護リングトンネルRaP_Dに切り替えます。トラフィックがノードEに到着すると、ノードDの障害も検出されますが、保護リングトンネルRaP_Dを使用してトラフィックをノードDに転送することはできません。ショートラッピングメカニズムを使用すると、現用リングから1回だけ保護切り替えを実行できます。保護リングトンネルへのトンネル。したがって、ノードEは、保護リングトンネルですでに伝送されているトラフィックを反対方向の現用リングトンネルに切り替えてはなりません（MUST NOT）。代わりに、ノードEはRaP_Dで受信したトラフィックをローカルで破棄します。これにより、リングトンネルの出力ノードで障害が発生したときに一時的なトラフィックループを回避できます。これは、各リング方向に別々の現用および保護リングトンネルを持つことの利点の1つも示しています。
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ */#
[RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B)
#\ */#
xxxxx*****[RcW_D(D)]****+---+
LSP1 +-- x D x-------------------| C |
xxxxx +---+
----- Physical Links xxxxx Failure Nodes
***** RcW_D ##### RaP_D
Figure 8: Short-Wrapping for Egress Node Failure
図8：出力ノード障害のショートラップ
With the steering protection mechanism, the ingress node (which adds traffic to the ring) performs switching from the working to the protection ring tunnel, and at the egress node, the traffic leaves the ring from the protection ring tunnel.
ステアリング保護メカニズムを使用すると、（リングにトラフィックを追加する）入力ノードが現用から保護リングトンネルへの切り替えを実行し、出力ノードでは、トラフィックは保護リングトンネルからリングを離れます。
When a failure occurs in the ring, the node that detects the failure with an OAM mechanism sends the failure information in the opposite direction of the failure hop by hop along the ring using an RPS request message and the ring-map information. When a ring node receives the RPS message that identifies a failure, it can determine the location of the fault by using the topology information of the ring map and updating the ring map accordingly; then, it can determine whether the LSPs entering the ring locally need to switch over or not. For LSPs that need to switch over, it will switch the LSPs from the working ring tunnels to their corresponding protection ring tunnels.
リングで障害が発生すると、OAMメカニズムで障害を検出したノードは、RPS要求メッセージとリングマップ情報を使用して、リングに沿ってホップごとに障害情報を障害ホップの反対方向に送信します。リングノードは、障害を識別するRPSメッセージを受信すると、リングマップのトポロジ情報を使用し、それに応じてリングマップを更新することにより、障害の場所を特定できます。次に、リングに入るLSPをローカルで切り替える必要があるかどうかを判断できます。切り替えが必要なLSPの場合、LSPは現用リングトンネルから対応する保護リングトンネルにLSPを切り替えます。
Ring Map of F +--LSP1
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+
|I|I|I|S|I|I| #/* *\# |I|I|S|I|I|I|
+-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+
[RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)]
#/* [RcW_D(F)] *\#
+-+-+-+-+-+-+-+ #/* *\#
|E|F|A|B|C|D|E| +---+ +---+ +-- LSP2
+-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+
|I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B|
+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+
#\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I|
[RaP_D(D)] #\* */# +-+-+-+-+-+-+
#\* */# [RaP_D(B)]
+-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+
|D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C|
+-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+
|I|I|I|I|I|S| LSP2 |S|I|I|I|I|I|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
----- Physical Links
***** RcW_D
##### RaP_D
I: Intact
S: Severed
Figure 9: Steering Operation and Protection Switching When Link C-D Fails
図9：リンクC-Dが失敗した場合のステアリング操作と保護切り替え
As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 enters the ring from Node B, and both of them have the same destination, which is Node D.
図9に示すように、LSP1はノードAからリングに入り、LSP2はノードBからリングに入り、どちらにも同じ宛先（ノードD）があります。
In normal state, LSP1 is carried by the clockwise working ring tunnel (RcW_D) through the path A->B->C->D, and the label operation is: [LSP1](Payload) -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> [RcW_D(D)|LSP1](NodeC) -> [LSP1](Payload).
通常の状態では、LSP1は時計回りのワーキングリングトンネル（RcW_D）によってパスA-> B-> C-> Dを介して伝送され、ラベル操作は次のようになります。[LSP1]（Payload）-> [RcW_D（B）| LSP1]（NodeA）-> [RcW_D（C）| LSP1]（NodeB）-> [RcW_D（D）| LSP1]（NodeC）-> [LSP1]（Payload）。
LSP2 is carried by the clockwise working ring tunnel (RcW_D) through the path B->C->D, and the label operation is: [LSP2](Payload) -> [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload).
LSP2は、パスB-> C-> Dを介して時計回りのワーキングリングトンネル（RcW_D）によって伝送され、ラベル操作は次のとおりです。[LSP2]（Payload）-> [RcW_D（C）| LSP2]（NodeB）-> [RcW_D（D）| LSP2]（NodeC）-> [LSP2]（Payload）。
If the link between Nodes C and D fails, according to the fault detection and distribution mechanisms, Node D will find out that there is a failure in the link between C and D, and it will update the link state of its ring topology, changing the link between C and D from normal to fault. In the direction that is opposite to the failure position, Node D will send the state report message to Node E, informing Node E of the fault between C and D, and E will update the link state of its ring topology accordingly, changing the link between C and D from normal to fault. In this way, the state report message is sent hop by hop in the clockwise direction. Similar to Node D, Node C will send the failure information in the anticlockwise direction.
ノードCとDの間のリンクに障害が発生すると、障害検出と配信メカニズムに従って、ノードDはCとDの間のリンクに障害があることを検出し、そのリングトポロジのリンク状態を更新して変更します。 CとDの間の正常から障害へのリンク。障害位置と反対の方向に、ノードDは状態レポートメッセージをノードEに送信し、ノードEにCとDの間の障害を通知し、Eはそれに応じてリングトポロジのリンク状態を更新し、リンクを変更します。 CとDの間で正常から障害までこのようにして、状態レポートメッセージはホップごとに時計回りに送信されます。ノードDと同様に、ノードCは障害情報を反時計回りに送信します。
When Node A receives the failure report message and updates the link state of its ring map, it is aware that there is a fault on the clockwise working ring tunnel to Node D (RcW_D), and LSP1 enters the ring locally and is carried by this ring tunnel; thus, Node A will decide to switch the LSP1 onto the anticlockwise protection ring tunnel to Node D (RaP_D). After the switchover, LSP1 will follow the path A->F->E->D, and the label operation is: [LSP1](Payload) -> [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> [LSP1](Payload).
ノードAが障害レポートメッセージを受信し、そのリングマップのリンク状態を更新すると、ノードD（RcW_D）への時計回りの動作リングトンネルに障害があり、LSP1がローカルでリングに入り、これによって実行されます。リングトンネル;したがって、ノードAはLSP1を反時計回りの保護リングトンネルからノードD（RaP_D）に切り替えることを決定します。スイッチオーバー後、LSP1はパスA-> F-> E-> Dをたどり、ラベル操作は次のようになります。[LSP1]（Payload）-> [RaP_D（F）| LSP1]（NodeA）-> [RaP_D（E）| LSP1]（NodeF）-> [RaP_D（D）| LSP1]（NodeE）-> [LSP1]（Payload）。
The same procedure also applies to the operation of LSP2. When Node B updates the link state of its ring topology, and finds out that the working ring tunnel RcW_D has failed, it will switch the LSP2 to the anticlockwise protection tunnel RaP_D. After the switchover, LSP2 goes through the path B->A->F->E->D, and the label operation is: [LSP2](Payload) -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](Payload).
同じ手順がLSP2の操作にも適用されます。ノードBがリングトポロジのリンク状態を更新し、現用のリングトンネルRcW_Dが失敗したことを検出すると、LSP2を反時計回りの保護トンネルRaP_Dに切り替えます。スイッチオーバー後、LSP2はパスB-> A-> F-> E-> Dを経由し、ラベル操作は次のようになります。[LSP2]（Payload）-> [RaP_D（A）| LSP2]（NodeB）-> [RaP_D（F）| LSP2]（NodeA）-> [RaP_D（E）| LSP2]（NodeF）-> [RaP_D（D）| LSP2]（NodeE）-> [LSP2]（Payload）。
Assume the link between Nodes A and B breaks down, as shown in Figure 10. Similar to the above failure case, Node B will detect a fault in the link between A and B, and it will update its ring map, changing the link state between A and B from normal to fault. The state report message is sent hop by hop in the clockwise direction, notifying every node that there is a fault between Nodes A and B, and every node updates the link state of its ring topology. As a result, Node A will detect a fault in the working ring tunnel to Node D, and switch LSP1 to the protection ring tunnel, while Node B determines that the working ring tunnel for LSP2 still works fine, and it will not perform the switchover.
図10に示すように、ノードAとBの間のリンクが故障すると想定します。上記の障害ケースと同様に、ノードBはAとBの間のリンクで障害を検出し、リングマップを更新してリンク状態を変更しますAとBの間で正常から障害まで。状態レポートメッセージは、時計回りの方向にホップごとに送信され、ノードAとBの間に障害があることをすべてのノードに通知し、すべてのノードがそのリングトポロジのリンク状態を更新します。その結果、ノードAはノードDへの現用リングトンネルの障害を検出し、LSP1を保護リングトンネルに切り替えますが、ノードBはLSP2の現用リングトンネルが引き続き正常に機能していると判断し、スイッチオーバーを実行しません。 。
/+-- LSP1
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+
|I|S|I|I|I|I| #/* x |S|I|I|I|I|I|
+-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+
[RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)]
#/* x /+-- LSP2
+-+-+-+-+-+-+-+ +---+ +---/ +-+-+-+-+-+-+-+
|E|F|A|B|C|D|E| | E | | B | |B|C|D|E|F|A|B|
+-+-+-+-+-+-+-+ +---+ +---+ +-+-+-+-+-+-+-+
|I|I|S|I|I|I| #\* */# |I|I|I|I|I|S|
+-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+
[RaP_D(D)] #\* */# [RaP_D(B)]
+-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+
|D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C|
+-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+
|I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I|
+-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+
----- Physical Links
***** RcW_D
##### RaP_D
Figure 10: Steering Operation and Protection Switching When Link A-B Fails
図10：リンクA-Bが失敗した場合のステアリング操作と保護切り替え
For a node failure that happens on a non-egress node, steering protection switching is similar to the link failure case as described in the previous section.
非出力ノードで発生するノード障害の場合、ステアリング保護切り替えは、前のセクションで説明したリンク障害の場合と同様です。
If the failure occurs at the egress node of the LSP, the ingress node will update its ring map according to the received RPS messages; it will also determine that the egress node is not reachable after the failure, thus it will not send traffic to either the working or the protection tunnel, and a traffic loop can be avoided.
LSPの出力ノードで障害が発生した場合、入力ノードは受信したRPSメッセージに従ってリングマップを更新します。また、障害発生後に出口ノードに到達できないと判断するため、現用トンネルと保護トンネルのどちらにもトラフィックを送信せず、トラフィックループを回避できます。
Interconnected ring topology is widely used in MPLS-TP networks. For a given ring, the interconnection node acts as the egress node for that ring, meaning that all LSPs using the interconnection node as an egress from one specific ring to another will use the same group of ring tunnels within the ring. This document will discuss two typical interconnected ring topologies:
相互接続リングトポロジは、MPLS-TPネットワークで広く使用されています。特定のリングでは、相互接続ノードはそのリングの出力ノードとして機能します。つまり、相互接続ノードを特定のリングから別のリングへの出力として使用するすべてのLSPは、リング内のリングトンネルの同じグループを使用します。このドキュメントでは、2つの一般的な相互接続リングトポロジについて説明します。
1. Single-node interconnected rings
1. シングルノード相互接続リング
In single-node interconnected rings, the connection between the two rings is through a single node. Because the interconnection node is in fact a single point of failure, this topology should be avoided in real transport networks.
単一ノードの相互接続されたリングでは、2つのリング間の接続は単一のノードを介して行われます。相互接続ノードは実際には単一障害点であるため、実際のトランスポートネットワークではこのトポロジを回避する必要があります。
Figure 11 shows the topology of single-node interconnected rings. Node C is the interconnection node between Ring1 and Ring2.
図11は、単一ノードで相互接続されたリングのトポロジーを示しています。ノードCは、Ring1とRing2の間の相互接続ノードです。
+---+ +---+ +---+ +---+
| A |------| B |----- -----| G |------| H |
+---+ +---+ \ / +---+ +---+
| \ / |
| \ +---+ / |
| Ring1 | C | Ring2 |
| / +---+ \ |
| / \ |
+---+ +---+ / \ +---+ +---+
| F |------| E |----- -----| J |------| I |
+---+ +---+ +---+ +---+
Figure 11: Single-Node Interconnected Rings
図11：単一ノード相互接続リング
2. Dual-node interconnected rings
2. デュアルノード相互接続リング
In dual-node interconnected rings, the connection between the two rings is through two nodes. The two interconnection nodes belong to both interconnected rings. This topology can recover from one interconnection node failure.
デュアルノード相互接続リングでは、2つのリング間の接続は2つのノードを経由します。 2つの相互接続ノードは、相互接続された両方のリングに属しています。このトポロジは、1つの相互接続ノードの障害から回復できます。
Figure 12 shows the topology of dual-node interconnected rings. Nodes C and D are the interconnection nodes between Ring1 and Ring2.
図12は、デュアルノード相互接続リングのトポロジーを示しています。ノードCとDは、Ring1とRing2の間の相互接続ノードです。
+---+ +---+ +---+ +---+ +---+
| A |------| B |------| C |------| G |------| H |
+---+ +---+ +---+ +---+ +---+
| | |
| | |
| Ring1 | Ring2 |
| | |
| | |
+---+ +---+ +---+ +---+ +---+
| F |------| E |------| D |------| J |------| I |
+---+ +---+ +---+ +---+ +---+
Figure 12: Dual-Node Interconnected Rings
図12：二重ノード相互接続リング
Interconnected rings can be treated as two independent rings. The RPS protocol operates on each ring independently. A failure that happens in one ring only triggers protection switching in the ring itself and does not affect the other ring, unless the failure is on the interconnection node. In this way, protection switching on each ring is the same as the mechanisms described in Section 4.3.
相互接続されたリングは、2つの独立したリングとして扱うことができます。 RPSプロトコルは、各リングで個別に動作します。一方のリングで発生した障害は、リング自体の保護切り替えをトリガーするだけで、相互接続ノードに障害がない限り、もう一方のリングには影響しません。このように、各リングの保護切り替えは、セクション4.3で説明したメカニズムと同じです。
The service LSPs that traverse the interconnected rings use the ring tunnels in each ring; within a given ring, the tunnel is selected using normal ring-selection procedures. The traversing LSPs are stitched on the interconnection node. On the interconnection node, the ring tunnel label of the source ring is popped, then LSP label is swapped; after that, the ring tunnel label of the destination ring is pushed.
相互接続されたリングを通過するサービスLSPは、各リングでリングトンネルを使用します。特定のリング内で、トンネルは通常のリング選択手順を使用して選択されます。トラバースLSPは相互接続ノードにステッチされます。相互接続ノードでは、ソースリングのリングトンネルラベルがポップされ、次にLSPラベルがスワップされます。その後、宛先リングのリングトンネルラベルがプッシュされます。
In the dual-node interconnected ring scenario, the two interconnection nodes can be managed as a virtual node group. In addition to the ring tunnels to each physical ring node, each ring SHOULD assign the working and protection ring tunnels to the virtual interconnection node group. In addition, on both nodes in the virtual interconnection node group, the same LSP label is assigned for each traversed LSP. This way, any interconnection node in the virtual node group can terminate the working or protection ring tunnels targeted to the virtual node group and stitch the service LSP from the source ring tunnel to the destination ring tunnel.
デュアルノード相互接続リングのシナリオでは、2つの相互接続ノードを仮想ノードグループとして管理できます。各物理リングノードへのリングトンネルに加えて、各リングは、仮想相互接続ノードグループに現用および保護リングトンネルを割り当てる必要があります（SHOULD）。さらに、仮想相互接続ノードグループの両方のノードで、通過した各LSPに同じLSPラベルが割り当てられます。このようにして、仮想ノードグループ内の相互接続ノードは、仮想ノードグループをターゲットとする現用または保護リングトンネルを終了し、サービスリングトンネルをソースリングトンネルから宛先リングトンネルにつなぐことができます。
When the service LSP passes through the interconnected rings, the direction of the working ring tunnels used on both rings SHOULD be the same. In dual-node interconnected rings, this ensures that in normal state the traffic passes only one of the two interconnection nodes and does not pass the link between the two interconnection nodes. The traffic will then only be switched to the protection path if the interconnection node that is in working path fails. For example, if the service LSP uses the clockwise working ring tunnel on Ring1, when the service LSP leaves Ring1 and enters Ring2, the working ring tunnel used on Ring2 should also follow the clockwise direction.
サービスLSPが相互接続されたリングを通過するとき、両方のリングで使用される現用リングトンネルの方向は同じである必要があります。これにより、デュアルノード相互接続リングでは、通常の状態でトラフィックが2つの相互接続ノードの1つだけを通過し、2つの相互接続ノード間のリンクを通過しないことが保証されます。トラフィックは、現用パスにある相互接続ノードに障害が発生した場合にのみ保護パスに切り替えられます。たとえば、サービスLSPがRing1で時計回りの現用リングトンネルを使用する場合、サービスLSPがRing1を出てRing2に入ると、Ring2で使用される現用リングトンネルも時計回りの方向に従います。
The same ring tunnels as described in Section 4.1 are used in each ring of the interconnected rings. In addition, ring tunnels to the virtual interconnection node group are established on each ring of the interconnected rings, that is:
セクション4.1で説明したのと同じリングトンネルが、相互接続されたリングの各リングで使用されます。さらに、仮想相互接続ノードグループへのリングトンネルは、相互接続されたリングの各リングで確立されます。
o one clockwise working ring tunnel to the virtual interconnection node group
o 仮想相互接続ノードグループへの1つの時計回りの動作リングトンネル
o one anticlockwise protection ring tunnel to the virtual interconnection node group
o 仮想相互接続ノードグループへの1つの反時計回りの保護リングトンネル
o one anticlockwise working ring tunnel to the virtual interconnection node group
o 仮想相互接続ノードグループへの1つの反時計回りの動作リングトンネル
o one clockwise protection ring tunnel to the virtual interconnection node group
o 仮想相互接続ノードグループへの1つの時計回りの保護リングトンネル
The ring tunnels to the virtual interconnection node group are shared by all LSPs that need to be forwarded to other rings. These ring tunnels can terminate at any node in the virtual interconnection node group.
仮想相互接続ノードグループへのリングトンネルは、他のリングに転送する必要があるすべてのLSPによって共有されます。これらのリングトンネルは、仮想相互接続ノードグループの任意のノードで終端できます。
For example, all the ring tunnels on Ring1 in Figure 13 are provisioned as follows:
たとえば、図13のRing1のすべてのリングトンネルは、次のようにプロビジョニングされます。
o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A
o ノードAへ：R1cW_A、R1aW_A、R1cP_A、R1aP_A
o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B
o ノードBへ：R1cW_B、R1aW_B、R1cP_B、R1aP_B
o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C
o ノードCへ：R1cW_C、R1aW_C、R1cP_C、R1aP_C
o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D
o ノードDへ：R1cW_D、R1aW_D、R1cP_D、R1aP_D
o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E
o と ので え： Ｒ１ｃＷ＿え、 Ｒ１あＷ＿え、 Ｒ１ｃＰ＿え、 Ｒ１あＰ＿え
o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F
o ノードFへ：R1cW_F、R1aW_F、R1cP_F、R1aP_F
o To the virtual interconnection node group (including Nodes F and A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A
o 仮想相互接続ノードグループ（ノードFおよびAを含む）へ：R1cW_F＆A、R1aW_F＆A、R1cP_F＆A、R1aP_F＆A
All the ring tunnels on Ring2 in Figure 13 are provisioned as follows:
図13のRing2のすべてのリングトンネルは、次のようにプロビジョニングされます。
o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A
o ノードAへ：R2cW_A、R2aW_A、R2cP_A、R2aP_A
o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F
o ノードFへ：R2cW_F、R2aW_F、R2cP_F、R2aP_F
o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G
o ノードGへ：R2cW_G、R2aW_G、R2cP_G、R2aP_G
o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H
o ノードHへ：R2cW_H、R2aW_H、R2cP_H、R2aP_H
o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I
o ノードIへ：R2cW_I、R2aW_I、R2cP_I、R2aP_I
o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J
o ノードJへ：R2cW_J、R2aW_J、R2cP_J、R2aP_J
o To the virtual interconnection node group (including Nodes F and A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A
o 仮想相互接続ノードグループ（ノードFおよびAを含む）へ：R2cW_F＆A、R2aW_F＆A、R2cP_F＆A、R2aP_F＆A
+---+ccccccccccccc+---+
| H |-------------| I |--->LSP1
+---+ +---+
c/a a\
c/a a\
c/a a\
+---+ +---+
| G | Ring2 | J |
+---+ +---+
c\a a/c
c\a a/c
c\a aaaaaaaaaaaaa a/c
+---+ccccccccccccc+---+
| F |-------------| A |
+---+ccccccccccccc+---+
c/aaaaaaaaaaaaaaaaaaa a\
c/ a\
c/ a\
+---+ +---+
| E | Ring1 | B |
+---+ +---+
c\a a/c
c\a a/c
c\a a/c
+---+aaaaaaaaaaaaa+---+
LSP1--->| D |-------------| C |
+---+ccccccccccccc+---+
Ring1: ccccccccccc R1cW_F&A aaaaaaaaaaa R1aP_F&A
Ring1：ccccccccccc R1cW_F＆A aaaaaaaaaaa R1aP_F＆A
Ring2: ccccccccccc R2cW_I aaaaaaaaaaa R2aP_I
Ring2：ccccccccccc R2cW_I aaaaaaaaaaa R2aP_I
Figure 13: Ring Tunnels for the Interconnected Rings
図13：相互接続されたリングのリングトンネル
As shown in Figure 13, for the service LSP1 that enters Ring1 at Node D and leaves Ring1 at Node F and continues to enter Ring2 at Node F and leaves Ring2 at Node I, the short-wrapping protection scheme is described as below.
図13に示すように、ノードDでリング1に入り、ノードFでリング1を離れ、ノードFでリング2に入り続け、ノードIでリング2を出るサービスLSP1の場合、ショートラップ保護スキームは次のようになります。
In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. At the interconnection Node F, the label used for the working ring tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the label used for the working ring tunnel R2cW_I in Ring2 will be pushed based on the inner LSP label lookup. The working path that the service LSP1 follows is: LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1.
通常の状態では、LSP1はRing1のR1cW_F＆AおよびRing2のR2cW_Iに従います。相互接続ノードFで、Ring1の現用リングトンネルR1cW_F＆Aに使用されるラベルがポップされ、LSPラベルが交換され、Ring2の現用リングトンネルR2cW_Iに使用されるラベルが内部LSPラベルルックアップに基づいてプッシュされます。サービスLSP1がたどる作業パスは、LSP1-> R1cW_F＆A（D-> E-> F）-> R2cW_I（F-> G-> H-> I）-> LSP1です。
In case of link failure, for example, when a failure occurs on the link between Nodes F and E, Node E will detect the failure and execute protection switching as described in Section 4.3.2. The path that the service LSP1 follows after switching change to: LSP1->R1cW_F &A(D->E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1.
リンク障害の場合、たとえば、ノードFとEの間のリンクで障害が発生すると、ノードEは障害を検出し、4.3.2で説明されているように保護切り替えを実行します。変更後のサービスLSP1がたどるパス：LSP1-> R1cW_F＆A（D-> E）-> R1aP_F＆A（E-> D-> C-> B-> A）-> R2cW_I（A-> F- > G-> H-> I）-> LSP1。
In case of a non-interconnection node failure, for example, when the failure occurs at Node E in Ring1, Node D will detect the failure and execute protection switching as described in Section 4.3.2. The path that the service LSP1 follows after switching becomes: LSP1->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1.
非相互接続ノードの障害が発生した場合、たとえば、Ring1のノードEで障害が発生した場合、ノードDは障害を検出し、4.3.2で説明されているように保護切り替えを実行します。切り替え後にサービスLSP1がたどるパスは、LSP1-> R1aP_F＆A（D-> C-> B-> A）-> R2cW_I（A-> F-> G-> H-> I）-> LSP1になります。
In case of an interconnection node failure, for example, when the failure occurs at the interconnection Node F, Node E in Ring1 will detect the failure and execute protection switching as described in Section 4.3.2. Node A in Ring2 will also detect the failure and execute protection switching as described in Section 4.3.2. The path that the service traffic LSP1 follows after switching is: LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1.
相互接続ノードに障害が発生した場合、たとえば、相互接続ノードFで障害が発生すると、Ring1のノードEが障害を検出し、4.3.2で説明するように保護切り替えを実行します。リング2のノードAも障害を検出し、4.3.2で説明するように保護切り替えを実行します。切り替え後にサービストラフィックLSP1がたどるパスは次のとおりです。LSP1-> R1cW_F＆A（D-> E）-> R1aP_F＆A（E-> D-> C-> B-> A）-> R2aP_I（A-> J-> I）-> LSP1。
As shown in Figure 13, in normal state, the service traffic LSP1 traverses D->E->F in Ring1 and F->G->H->I in Ring2. Nodes A and F are the interconnection nodes. When both links between Nodes F and G and between Nodes F and A fail, the ring tunnel from Node F to Node I in Ring2 becomes unreachable. However, the other interconnection Node A is still available, and LSP1 can still reach Node I via Node A.
図13に示すように、通常の状態では、サービストラフィックLSP1は、Ring1でD-> E-> F、Ring2でF-> G-> H-> Iを通過します。ノードAとFは相互接続ノードです。ノードFとGの間、およびノードFとAの間の両方のリンクに障害が発生すると、ノードFからリング2のノードIへのリングトンネルが到達不能になります。ただし、他の相互接続ノードAは引き続き使用可能であり、LSP1はノードAを介してノードIに到達できます。
In order to achieve this, the interconnection nodes need to know the ring topology of each ring so that they can judge whether a node is reachable. This judgment is based on the knowledge of the ring map and the fault location. The ring map can be obtained from the Network Management System (NMS) or topology discovery mechanisms. The fault location can be obtained by transmitting the fault information around the ring. The nodes that detect the failure will transmit the fault information in the opposite direction hop by hop using the RPS protocol message. When the interconnection node receives the message that informs the failure, it will calculate the location of the fault according to the topology information that is maintained by itself and determines whether the LSPs entering the ring at itself can reach the destination. If the destination node is reachable, the LSP will leave the source ring and enter the destination ring. If the destination node is not reachable, the LSP will switch to the anticlockwise protection ring tunnel.
これを実現するには、相互接続ノードが各リングのリングトポロジーを認識して、ノードが到達可能かどうかを判断できるようにする必要があります。この判断は、リングマップと障害の場所の知識に基づいています。リングマップは、ネットワーク管理システム（NMS）またはトポロジー検出メカニズムから取得できます。リングの周りに障害情報を送信することにより、障害の場所を取得できます。障害を検出したノードは、RPSプロトコルメッセージを使用して、ホップごとに反対方向に障害情報を送信します。相互接続ノードは、障害を通知するメッセージを受信すると、自身が保持しているトポロジ情報に従って障害の場所を計算し、リングに入るLSPが宛先に到達できるかどうかを判断します。宛先ノードに到達できる場合、LSPは送信元リングを離れ、宛先リングに入ります。宛先ノードに到達できない場合、LSPは反時計回りの保護リングトンネルに切り替えます。
In Figure 13, Node F determines that the ring tunnel to Node I is unreachable; the service LSP1 for which the destination node on Ring2 is Node I MUST switch to the protection ring tunnel (R1aP_F&A), and consequently, the service traffic LSP1 traverses the interconnected rings at Node A. Node A will pop the ring tunnel label of Ring1 and push the ring tunnel label of Ring2 and send the traffic to Node I via the ring tunnel (R2aW_I).
図13では、ノードFはノードIへのリングトンネルに到達できないと判断します。 Ring2の宛先ノードがノードであるサービスLSP1はノードIが保護リングトンネル（R1aP_F＆A）に切り替えなければならず、その結果、サービストラフィックLSP1はノードAで相互接続されたリングを通過します。ノードAはリング1のリングトンネルラベルをポップし、 Ring2のリングトンネルラベルをプッシュし、リングトンネル（R2aW_I）を介してノードIにトラフィックを送信します。
This section provides comparison between RPS and Protection State Coordination (PSC) [RFC6378] [RFC6974] on ring topologies. This can be helpful to explain the reason of defining a new protocol for ring protection switching.
このセクションでは、リングトポロジにおけるRPSと保護状態調整（PSC）[RFC6378] [RFC6974]の比較について説明します。これは、リング保護切り替え用の新しいプロトコルを定義する理由を説明するのに役立ちます。
The PSC protocol [RFC6378] is designed for point-to-point LSPs, on which the protection switching can only be performed on one or both of the endpoints of the LSP. The RPS protocol is designed for ring tunnels, which consist of multiple ring nodes, and the failure could happen on any segment of the ring; thus, RPS is capable of identifying and handling the different failures on the ring and coordinating the protection-switching behavior of all the nodes on the ring. As will be specified in the following sections, this is achieved with the introduction of the "pass-through" state for the ring nodes, and the location of the protection request is identified via the node IDs in the RPS request message.
PSCプロトコル[RFC6378]はポイントツーポイントLSP向けに設計されており、LSPのエンドポイントの一方または両方でのみ保護切り替えを実行できます。 RPSプロトコルは、複数のリングノードで構成されるリングトンネル用に設計されており、障害はリングの任意のセグメントで発生する可能性があります。したがって、RPSはリング上のさまざまな障害を識別して処理し、リング上のすべてのノードの保護切り替え動作を調整することができます。次のセクションで説明するように、これはリングノードの「パススルー」状態の導入によって実現され、保護要求の場所はRPS要求メッセージのノードIDによって識別されます。
Taking a ring topology with N nodes as an example:
例として、Nノードのリングトポロジを取り上げます。
With the mechanism specified in [RFC6974], on every ring node, a linear protection configuration has to be provisioned with every other node in the ring, i.e., with (N-1) other nodes. This means that on every ring node there will be (N-1) instances of the PSC protocol. And in order to detect faults and to transport the PSC message, each instance shall have a MEP on the working path and a MEP on the protection path, respectively. This means that every node on the ring needs to be configured with (N-1) * 2 MEPs.
[RFC6974]で指定されたメカニズムでは、すべてのリングノードで、線形保護構成をリング内の他のすべてのノード、つまり（N-1）個の他のノードにプロビジョニングする必要があります。これは、すべてのリングノードにPSCプロトコルの（N-1）インスタンスがあることを意味します。また、障害を検出してPSCメッセージを転送するために、各インスタンスには、それぞれ現用パスにMEPがあり、保護パスにMEPがあります。これは、リング上のすべてのノードが（N-1）* 2 MEPで構成される必要があることを意味します。
With the mechanism defined in this document, on every ring node there will only be a single instance of the RPS protocol. In order to detect faults and to transport the RPS message, each node only needs to have a MEP on the section to its adjacent nodes, respectively. In this way, every ring node only needs to be configured with 2 MEPs.
このドキュメントで定義されているメカニズムを使用すると、すべてのリングノードにRPSプロトコルのインスタンスが1つだけ存在します。障害を検出し、RPSメッセージを転送するために、各ノードは、それぞれ隣接するノードへのセクションにMEPを持つ必要があります。この方法では、すべてのリングノードに2つのMEPを設定するだけで済みます。
As shown in the above example, RPS is designed for ring topologies and can achieve ring protection efficiently with minimum protection instances and OAM entities, which meets the requirements on topology-specific recovery mechanisms as specified in [RFC5654].
上記の例に示すように、RPSはリングトポロジ用に設計されており、最小限の保護インスタンスとOAMエンティティで効率的にリング保護を実現できます。これは、[RFC5654]で指定されているトポロジ固有の回復メカニズムの要件を満たします。
The RPS protocol defined in this section is used to coordinate the protection-switching action of all the ring nodes in the same ring.
このセクションで定義されているRPSプロトコルは、同じリング内のすべてのリングノードの保護切り替えアクションを調整するために使用されます。
The protection operation of the ring tunnels is controlled with the help of the RPS protocol. The RPS processes in each of the individual ring nodes that form the ring MUST communicate using the Generic Associated Channel (G-ACh). The RPS protocol is applicable to all the three ring protection modes. This section takes the short-wrapping mechanism described in Section 4.3.2 as an example.
リングトンネルの保護動作は、RPSプロトコルを使用して制御されます。リングを形成する個々のリングノードのそれぞれのRPSプロセスは、Generic Associated Channel（G-ACh）を使用して通信する必要があります。 RPSプロトコルは、3つのリング保護モードすべてに適用できます。このセクションでは、例として、セクション4.3.2で説明されている短いラッピングメカニズムを取り上げます。
The RPS protocol is used to distribute the ring status information and RPS requests to all the ring nodes. Changes in the ring status information and RPS requests can be initiated automatically based on link status or caused by external commands.
RPSプロトコルは、リングステータス情報とRPS要求をすべてのリングノードに配信するために使用されます。リングステータス情報とRPS要求の変更は、リンクステータスに基づいて、または外部コマンドによって自動的に開始できます。
Each node on the ring is uniquely identified by assigning it a node ID. The node ID MUST be unique on each ring. The maximum number of nodes on the ring supported by the RPS protocol is 127. The node ID SHOULD be independent of the order in which the nodes appear on the ring. The node ID is used to identify the source and destination nodes of each RPS request.
リング上の各ノードは、ノードIDを割り当てることによって一意に識別されます。ノードIDは各リングで一意である必要があります。 RPSプロトコルでサポートされるリング上のノードの最大数は127です。ノードIDは、ノードがリングに表示される順序とは無関係である必要があります（SHOULD）。ノードIDは、各RPS要求の送信元ノードと宛先ノードを識別するために使用されます。
Every node obtains the ring topology either by configuration or via some topology discovery mechanism. The ring map consists of the ring topology information, and connectivity status (Intact or Severed) between the adjacent ring nodes, which is determined via the OAM message exchanged between the adjacent nodes. The ring map is used by every ring node to determine the switchover behavior of the ring tunnels.
すべてのノードは、構成によって、またはトポロジー検出メカニズムを介して、リングトポロジーを取得します。リングマップは、リングトポロジ情報と、隣接するノード間で交換されるOAMメッセージを介して決定される隣接するリングノード間の接続ステータス（インタクトまたは切断）で構成されます。リングマップは、リングトンネルのスイッチオーバー動作を決定するために、すべてのリングノードによって使用されます。
As shown in Figure 14, when no protection switching is active on the ring, each node MUST send RPS requests with No Request (NR) to its two adjacent nodes periodically. The transmission interval of RPS requests is specified in Section 5.2.1.
図14に示すように、リング上で保護切り替えがアクティブでない場合、各ノードは、要求なし（NR）のRPS要求を2つの隣接ノードに定期的に送信する必要があります。 RPSリクエストの送信間隔は5.2.1項で規定されています。
+---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR)
-------| A |-------------| B |-------------| C |-------
(NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+
Figure 14: RPS Communication between the Ring Nodes in Case of No Failure in the Ring
図14：リングに障害がない場合のリングノード間のRPS通信
As shown in Figure 15, when a node detects a failure and determines that protection switching is required, it MUST send the appropriate RPS request in both directions to the destination node. The destination node is the other node that is adjacent to the identified failure. When a node that is not the destination node receives an RPS request and it has no higher-priority local request, it MUST transfer in the same direction the RPS request as received. In this way, the switching nodes can maintain RPS protocol communication in the ring. The RPS request MUST be terminated by the destination node of the message. If an RPS request with the node itself set as the source node is received, this message MUST be dropped and not be forwarded to the next node.
図15に示すように、ノードが障害を検出し、保護切り替えが必要であると判断した場合、ノードは適切なRPS要求を双方向で宛先ノードに送信する必要があります。宛先ノードは、識別された障害に隣接するもう一方のノードです。宛先ノードではないノードがRPS要求を受信し、優先順位の高いローカル要求がない場合、受信したRPS要求と同じ方向に転送する必要があります。このようにして、スイッチングノードはリング内でRPSプロトコル通信を維持できます。 RPS要求は、メッセージの宛先ノードによって終了する必要があります。ノード自体がソースノードとして設定されたRPS要求が受信された場合、このメッセージはドロップされ、次のノードに転送されない必要があります。
+---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF)
-------| A |-------------| B |----- X -----| C |-------
(SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+
Figure 15: RPS Communication between the Ring Nodes in Case of Failure between Nodes B and C
図15：ノードBとCの間で障害が発生した場合のリングノード間のRPS通信
Note that in the case of a bidirectional failure such as a cable cut, the two adjacent nodes detect the failure and send each other an RPS request in opposite directions.
ケーブルの切断などの双方向障害の場合、2つの隣接ノードが障害を検出し、RPS要求を反対方向に送信します。
o In rings utilizing the wrapping protection, each node detects the failure or receives the RPS request as the destination node MUST perform the switch from/to the working ring tunnels to/from the protection ring tunnels if it has no higher-priority active RPS request.
o ラップ保護を利用するリングでは、宛先ノードがより高い優先度のアクティブRPS要求を持たない場合、宛先ノードは保護リングトンネルとの間の切り替えを実行する必要があるため、各ノードは障害を検出するか、RPS要求を受信します。
o In rings utilizing the short-wrapping protection, each node detects the failure or receives the RPS request as the destination node MUST perform the switch only from the working ring tunnels to the protection ring tunnels.
o ショートラッピング保護を利用するリングでは、宛先ノードが現用リングトンネルから保護リングトンネルへの切り替えのみを実行する必要があるため、各ノードは障害を検出するか、RPS要求を受信します。
o In rings utilizing the steering protection, when a ring switch is required, any node MUST perform the switches if its added/dropped traffic is affected by the failure. Determination of the affected traffic MUST be performed by examining the RPS requests (indicating the nodes adjacent to the failure or failures) and the stored ring map (indicating the relative position of the failure and the added traffic destined towards that failure).
o ステアリング保護を利用するリングでは、リングの切り替えが必要な場合、追加またはドロップされたトラフィックが障害の影響を受ける場合、どのノードも切り替えを実行する必要があります。影響を受けるトラフィックの決定は、RPS要求（1つまたは複数の障害に隣接するノードを示す）と保存されたリングマップ（障害の相対位置とその障害を宛先とする追加のトラフィックを示す）を調べることによって実行する必要があります。
When the failure has cleared and the Wait-to-Restore (WTR) timer has expired, the nodes that generate the RPS requests MUST drop their respective switches and MUST generate an RPS request carrying the NR code. The node receiving such an RPS request from both directions MUST drop its protection switches.
障害が解消し、Wait-to-Restore（WTR）タイマーが切れた場合、RPS要求を生成するノードはそれぞれのスイッチをドロップし、NRコードを運ぶRPS要求を生成する必要があります。このようなRPS要求を両方向から受信するノードは、保護スイッチをドロップする必要があります。
A protection switch MUST be initiated by one of the criteria specified in Section 5.3. A failure of the RPS protocol or controller MUST NOT trigger a protection switch.
保護切り替えは、セクション5.3で指定された基準の1つによって開始する必要があります。 RPSプロトコルまたはコントローラーの障害は、保護切り替えをトリガーしてはなりません（MUST NOT）。
Ring switches MUST be preempted by higher-priority RPS requests. For example, consider a protection switch that is active due to a manual switch request on the given link, and another protection switch is required due to a failure on another link. Then an RPS request MUST be generated, the former protection switch MUST be dropped, and the latter protection switch established.
リングの切り替えは、優先度の高いRPS要求によって優先される必要があります。たとえば、特定のリンクでの手動切り替え要求によりアクティブになっている保護スイッチを考えて、別のリンクでの障害により別の保護スイッチが必要であるとします。次に、RPS要求を生成する必要があり、前者の保護スイッチをドロップしなければならず、後者の保護スイッチを確立する必要があります。
The MPLS-TP Shared-Ring Protection mechanism supports multiple protection switches in the ring, resulting in the ring being segmented into two or more separate segments. This may happen when several RPS requests of the same priority exist in the ring due to multiple failures or external switch commands.
MPLS-TP共有リング保護メカニズムは、リング内の複数の保護スイッチをサポートするため、リングは2つ以上の個別のセグメントにセグメント化されます。これは、複数の障害または外部スイッチコマンドが原因で、同じ優先度の複数のRPS要求がリング内に存在する場合に発生することがあります。
Proper operation of the MSRP mechanism relies on all nodes using their ring map to determine the state of the ring (nodes and links). In order to accommodate ring state knowledge, the RPS requests MUST be sent in both directions during a protection switch.
MSRPメカニズムの適切な動作は、リングマップを使用するすべてのノードに依存して、リングの状態（ノードとリンク）を決定します。リング状態の知識に対応するために、保護切り替え中にRPS要求を両方向に送信する必要があります。
A new RPS request MUST be transmitted immediately when a change in the transmitted status occurs.
送信されたステータスに変化が生じた場合、新しいRPS要求をただちに送信する必要があります。
The first three RPS protocol messages carrying a new RPS request MUST be transmitted as fast as possible. For fast protection switching within 50 ms, the interval of the first three RPS protocol messages SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted with the interval of 5 seconds. A ring node that is not the destination of the received RPS message MUST forward it to the next node along the ring immediately.
新しいRPS要求を伝える最初の3つのRPSプロトコルメッセージは、可能な限り高速に送信する必要があります。 50ミリ秒以内の高速保護スイッチングの場合、最初の3つのRPSプロトコルメッセージの間隔は3.3ミリ秒である必要があります。連続したRPSリクエストは、5秒間隔で送信する必要があります（SHOULD）。受信したRPSメッセージの宛先ではないリングノードは、リングに沿って次のノードにすぐに転送する必要があります。
Figure 16 depicts the format of an RPS packet that is sent on the G-ACh. The Channel Type field is set to indicate that the message is an RPS message.
図16は、G-AChで送信されるRPSパケットのフォーマットを示しています。 Channel Typeフィールドは、メッセージがRPSメッセージであることを示すように設定されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RPS Channel Type (0x002A) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Node ID | Src Node ID | Request | M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: G-ACh RPS Packet Format
図16：G-ACh RPSパケット形式
The following fields MUST be provided:
次のフィールドを指定する必要があります。
o Destination Node ID: The destination node ID MUST always be set to the value of the node ID of the adjacent node. The node ID MUST be unique on each ring. Valid destination node ID values are 1-127.
o 宛先ノードID：宛先ノードIDは、常に隣接ノードのノードIDの値に設定する必要があります。ノードIDは各リングで一意である必要があります。有効な宛先ノードIDの値は1〜127です。
o Source Node ID: The source node ID MUST always be set to the ID value of the node generating the RPS request. The node ID MUST be unique on each ring. Valid source node ID values are 1-127.
o ソースノードID：ソースノードIDは、常にRPS要求を生成するノードのID値に設定する必要があります。ノードIDは各リングで一意である必要があります。有効なソースノードID値は1〜127です。
o Protection-Switching Mode (M): This 2-bit field indicates the protection-switching mode used by the sending node of the RPS message. This can be used to check that the ring nodes on the same ring use the same protection-switching mechanism. The defined values of the M field are listed as below:
o 保護スイッチングモード（M）：この2ビットのフィールドは、RPSメッセージの送信ノードが使用する保護スイッチングモードを示します。これを使用して、同じリング上のリングノードが同じ保護切り替えメカニズムを使用していることを確認できます。 Mフィールドの定義された値は以下のとおりです。
+------------------+-----------------------------+
| Bits (MSB - LSB) | Protection-Switching Mode |
+------------------+-----------------------------+
| 0 0 | Reserved |
| 0 1 | Wrapping |
| 1 0 | Short-Wrapping |
| 1 1 | Steering |
+------------------+-----------------------------+
Note: MSB = most significant bit LSB = least significant bit
注：MSB =最上位ビットLSB =最下位ビット
o RPS Request Code: A code consisting of 8 bits as specified below:
o RPS要求コード：以下に指定する8ビットで構成されるコード：
+------------------+-----------------------------+----------+
| Bits | Condition, State, | Priority |
| (MSB - LSB) | or External Request | |
+------------------+-----------------------------+----------+
| 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest |
| 0 0 0 0 1 1 0 1 | Forced Switch (FS) | |
| 0 0 0 0 1 0 1 1 | Signal Fail (SF) | |
| 0 0 0 0 0 1 1 0 | Manual Switch (MS) | |
| 0 0 0 0 0 1 0 1 | Wait-to-Restore (WTR) | |
| 0 0 0 0 0 0 1 1 | Exercise (EXER) | |
| 0 0 0 0 0 0 0 1 | Reverse Request (RR) | |
| 0 0 0 0 0 0 0 0 | No Request (NR) | lowest |
+------------------+-----------------------------+----------+
Idle state: A node is in the idle state when it has no RPS request and is sending and receiving an NR code to/from both directions.
アイドル状態：RPS要求がなく、双方向でNRコードを送受信している場合、ノードはアイドル状態です。
Switching state: A node not in the idle or pass-through states is in the switching state.
切り替え状態：アイドル状態またはパススルー状態でないノードは切り替え状態です。
Pass-through state: A node is in the pass-through state when its highest priority RPS request is a request not destined to it or generated by it. The pass-through is bidirectional.
パススルー状態：ノードは、その最高優先順位のRPS要求が宛先ではない、またはノードによって生成された要求である場合、パススルー状態になります。パススルーは双方向です。
A node in the idle state MUST generate the NR request in both directions.
アイドル状態のノードは、双方向でNR要求を生成する必要があります。
A node in the idle state MUST terminate RPS requests that flow in both directions.
アイドル状態のノードは、双方向に流れるRPS要求を終了する必要があります。
A node in the idle state MUST block the traffic flow on protection ring tunnels in both directions.
アイドル状態のノードは、両方向の保護リングトンネル上のトラフィックフローをブロックする必要があります。
A node in the switching state MUST generate an RPS request to its adjacent node with its highest RPS request code in both directions when it detects a failure or receives an external command.
スイッチング状態のノードは、障害を検出するか外部コマンドを受信したときに、双方向で最も高いRPS要求コードを持つ隣接ノードへのRPS要求を生成する必要があります。
In a bidirectional failure condition, both of the nodes adjacent to the failure detect the failure and send the RPS request in both directions with the destination set to each other; while each node can only receive the RPS request via the long path, the message sent via the short path will get lost due to the bidirectional failure. Here, the short path refers to the shorter path on the ring between the source and destination node of the RPS request, and the long path refers to the longer path on the ring between the source and destination node of the RPS request. Upon receipt of the RPS request on the long path, the destination node of the RPS request MUST send an RPS request with its highest request code periodically along the long path to the other node adjacent to the failure.
双方向障害状態では、障害に隣接する両方のノードが障害を検出し、RPS要求を宛先を互いに設定して両方向に送信します。各ノードは長いパスを介してのみRPS要求を受信できますが、短いパスを介して送信されたメッセージは、双方向障害のため失われます。ここで、短いパスとはRPS要求の送信元ノードと宛先ノード間のリング上の短いパスを指し、長いパスとはRPS要求の送信元ノードと宛先ノード間のリング上の長いパスを指します。長いパスでRPS要求を受信すると、RPS要求の宛先ノードは、最も高い要求コードを持つRPS要求を、長いパスに沿って、障害に隣接する他のノードに定期的に送信する必要があります。
In a unidirectional failure condition, the node that detects the failure MUST send the RPS request in both directions with the destination node set to the other node adjacent to the failure. The destination node of the RPS request cannot detect the failure itself but will receive an RPS request from both the short path and the long path. The destination node MUST acknowledge the received RPS requests by replying with an RPS request with the RR code on the short path and an RPS request with the received RPS request code on the long path. Accordingly, when the node that detects the failure receives the RPS request with RR code on the short path, then the RPS request received from the same node along the long path SHOULD be ignored.
単一方向の障害状態では、障害を検出したノードは、宛先ノードを障害に隣接する他のノードに設定して、RPS要求を両方向に送信する必要があります。 RPS要求の宛先ノード自体は障害を検出できませんが、ショートパスとロングパスの両方からRPS要求を受信します。宛先ノードは、ショートパス上のRRコードを含むRPSリクエストと、ロングパス上の受信したRPSリクエストコードを含むRPSリクエストで返信することにより、受信したRPSリクエストを確認する必要があります。したがって、障害を検出したノードが短いパスでRRコードを含むRPS要求を受信した場合、長いパスに沿って同じノードから受信したRPS要求は無視する必要があります（SHOULD）。
A node in the switching state MUST terminate the received RPS requests in both directions and not forward it further along the ring.
スイッチング状態のノードは、受信したRPS要求を両方向で終了し、リングに沿ってそれ以上転送しない必要があります。
The following switches as defined in Section 5.3.1 MUST be allowed to coexist:
セクション5.3.1で定義されている次のスイッチは、共存できる必要があります。
o LP and LP
o LPとLP
o FS and FS
o FSおよびFS
o SF and SF
o SFとSF
o FS and SF
o FSおよびSF
When multiple MS RPS requests exist at the same time addressing different links and there is no higher-priority request on the ring, no switch SHOULD be executed and existing switches MUST be dropped. The nodes MUST still signal an RPS request with the MS code.
複数のMS RPS要求が同時に異なるリンクをアドレス指定して存在し、リングに優先度の高い要求がない場合、スイッチは実行されるべきではなく（SHOULD）、既存のスイッチはドロップされなければなりません（MUST）。ノードは依然としてMSコードを使用してRPS要求を通知する必要があります。
Multiple EXER requests MUST be allowed to coexist in the ring.
複数のEXER要求がリング内で共存できるようにする必要があります。
A node in a ring-switching state that receives the external command LP for the affected link MUST drop its switch and MUST signal NR for the locked link if there is no other RPS request on another link. The node still SHOULD signal a relevant RPS request for another link.
影響を受けるリンクの外部コマンドLPを受信するリング切り替え状態のノードは、そのスイッチをドロップする必要があり、別のリンクに他のRPS要求がない場合は、ロックされたリンクのNRを通知する必要があります。ノードはまだ別のリンクに関連するRPS要求を通知する必要があります（SHOULD）。
When a node is in a pass-through state, it MUST transfer the received RPS request unchanged in the same direction.
ノードがパススルー状態にある場合、受信したRPS要求を変更せずに同じ方向に転送する必要があります。
When a node is in a pass-through state, it MUST enable the traffic flow on protection ring tunnels in both directions.
ノードがパススルー状態にある場合、双方向の保護リングトンネルでトラフィックフローを有効にする必要があります。
All state transitions are triggered by an incoming RPS request change, a WTR expiration, an externally initiated command, or locally detected MPLS-TP section failure conditions.
すべての状態遷移は、着信RPS要求の変更、WTRの有効期限、外部で開始されたコマンド、またはローカルで検出されたMPLS-TPセクションの障害状態によってトリガーされます。
RPS requests due to a locally detected failure, an externally initiated command, or a received RPS request shall preempt existing RPS requests in the prioritized order given in Section 5.2.2, unless the requests are allowed to coexist.
ローカルで検出された障害、外部で開始されたコマンド、または受信したRPS要求によるRPS要求は、要求の共存が許可されていない限り、セクション5.2.2で指定された優先順位で既存のRPS要求よりも優先されます。
The transition from the idle state to pass-through state MUST be triggered by a valid RPS request change, in any direction, from the NR code to any other code, as long as the new request is not destined to the node itself. Both directions move then into a pass-through state, so that traffic entering the node through the protection ring tunnels are transferred transparently through the node.
アイドル状態からパススルー状態への遷移は、新しい要求がノード自体に向けられていない限り、NRコードから他のコードへの有効なRPS要求の変更によってトリガーされる必要があります。その後、両方向がパススルー状態に移行するため、保護リングトンネルを介してノードに入るトラフィックは、ノードを介して透過的に転送されます。
A node MUST revert from pass-through state to the idle state when an RPS request with an NR code is received in both directions. Then both directions revert simultaneously from the pass-through state to the idle state.
NRコードを含むRPS要求が両方向で受信された場合、ノードはパススルー状態からアイドル状態に戻る必要があります。次に、両方向が同時にパススルー状態からアイドル状態に戻ります。
Transition of a node from the idle state to the switching state MUST be triggered by one of the following conditions:
ノードのアイドル状態からスイッチング状態への遷移は、次の条件のいずれかによってトリガーされる必要があります。
o A valid RPS request change from the NR code to any code received on either the long or the short path and is destined to this node
o 有効なRPS要求は、NRコードから、ロングパスまたはショートパスのいずれかで受信され、このノードを宛先とする任意のコードに変更されます。
o An externally initiated command for this node o The detection of an MPLS-TP section-layer failure at this node
oこのノードに対して外部で開始されたコマンドoこのノードでのMPLS-TPセクション層障害の検出
Actions taken at a node in the idle state upon transition to the switching state are:
スイッチング状態への移行時にアイドル状態のノードで行われるアクションは次のとおりです。
o For all protection-switch requests, except EXER and LP, the node MUST execute the switch
o EXERとLPを除くすべての保護切り替え要求について、ノードは切り替えを実行する必要があります
o For EXER, and LP, the node MUST signal the appropriate request but not execute the switch
o EXERおよびLPの場合、ノードは適切な要求を通知する必要がありますが、スイッチを実行してはなりません
In one of the following conditions, transition from the switching state to the idle state MUST be triggered:
次の条件のいずれかで、スイッチング状態からアイドル状態への遷移をトリガーする必要があります。
o On the node that triggers the protection switching, when the WTR time expires or an externally initiated command is cleared, the node MUST transit from switching state to Idle State and signal the NR code using RPS message in both directions.
o 保護切り替えをトリガーするノードで、WTR時間が経過するか、外部で開始されたコマンドがクリアされると、ノードは切り替え状態からアイドル状態に遷移し、双方向のRPSメッセージを使用してNRコードを通知する必要があります。
o On the node that enters the switching state due to the received RPS request: upon reception of the NR code from both directions, the head-end node MUST drop its switch, transition to idle state, and signal the NR code in both directions.
o 受信したRPS要求が原因でスイッチング状態になったノード：両方向からNRコードを受信すると、ヘッドエンドノードはスイッチをドロップし、アイドル状態に移行して、両方向でNRコードを通知する必要があります。
When a node that is currently executing any protection switch receives a higher-priority RPS request (due to a locally detected failure, an externally initiated command, or a ring protection switch request destined to it) for the same link, it MUST update the priority of the switch it is executing to the priority of the received RPS request.
保護切り替えを現在実行しているノードが同じリンクの（ローカルで検出された障害、外部で開始されたコマンド、または宛先が指定されたリング保護切り替え要求により）優先順位の高いRPS要求を受信した場合、優先順位を更新する必要があります実行中のスイッチの、受信したRPS要求の優先順位。
When a failure condition clears at a node, the node MUST enter WTR condition and remain in it for the appropriate time-out interval, unless:
ノードで障害状態が解消すると、ノードはWTR状態に入り、次の場合を除いて、適切なタイムアウト間隔の間その状態を維持する必要があります。
o A different RPS request with a higher priority than WTR is received
o WTRよりも優先度の高い別のRPS要求が受信された
o Another failure is detected
o 別の障害が検出されました
o An externally initiated command becomes active
o 外部で開始されたコマンドがアクティブになります
The node MUST send out a WTR code on both the long and short paths.
ノードはロングパスとショートパスの両方でWTRコードを送信する必要があります。
When a node that is executing a switch in response to an incoming SF RPS request (not due to a locally detected failure) receives a WTR code (unidirectional failure case), it MUST send out the RR code on the short path and the WTR on the long path.
（ローカルで検出された障害ではなく）着信SF RPS要求に応答してスイッチを実行しているノードがWTRコード（単方向障害の場合）を受信した場合、ノードはショートパスでRRコードを送信し、長い道のり。
When a node that is currently executing a switch receives an RPS request for a non-adjacent link of higher priority than the switch it is executing, it MUST drop its switch immediately and enter the pass-through state.
現在スイッチを実行しているノードが、実行しているスイッチよりも優先度の高い非隣接リンクのRPS要求を受信した場合、ノードはただちにスイッチをドロップし、パススルー状態に入る必要があります。
The transition of a node from pass-through to switching state MUST be triggered by:
ノードのパススルーからスイッチング状態への遷移は、以下によってトリガーされる必要があります。
o An equal priority, a higher priority, or an allowed coexisting externally initiated command
o 同等の優先順位、より高い優先順位、または許可された共存の外部で開始されたコマンド
o The detection of an equal priority, a higher priority, or an allowed coexisting automatic initiated command
o 等しい優先度、高い優先度、または許可された共存自動開始コマンドの検出
o The receipt of an equal, a higher priority, or an allowed coexisting RPS request destined to this node
o このノードを宛先とする等しい、より高い優先度、または許可された共存RPS要求の受信
Administrative commands can be initiated by the network operator through the Network Management System (NMS). The operator command may be transmitted to the appropriate node via the MPLS-TP RPS message.
管理コマンドは、ネットワーク管理者がネットワーク管理システム（NMS）を介して開始できます。オペレータコマンドは、MPLS-TP RPSメッセージを介して適切なノードに送信できます。
The following commands can be transferred by the RPS message:
次のコマンドは、RPSメッセージによって転送できます。
o Lockout of Protection (LP): This command prevents any protection activity and prevents using ring switches anywhere in the ring. If any ring switches exist in the ring, this command causes the switches to drop.
o 保護のロックアウト（LP）：このコマンドは、保護活動を防止し、リング内の任意の場所でのリングスイッチの使用を防止します。リングにリングスイッチが存在する場合、このコマンドによりスイッチがドロップします。
o Forced Switch (FS) to protection: This command performs the ring switch of normal traffic from the working entity to the protection entity for the link between the node at which the command is initiated and the adjacent node to which the command is directed. This switch occurs regardless of the state of the MPLS-TP section for the requested link, unless a higher-priority switch request exists.
o 保護への強制切り替え（FS）：このコマンドは、コマンドが開始されたノードとコマンドが送信された隣接ノードとの間のリンクに対して、動作エンティティから保護エンティティへの通常のトラフィックのリング切り替えを実行します。この切り替えは、優先順位の高い切り替え要求が存在しない限り、要求されたリンクのMPLS-TPセクションの状態に関係なく行われます。
o Manual Switch (MS) to protection: This command performs the ring switch of the normal traffic from the working entity to the protection entity for the link between the node at which the command is initiated and the adjacent node to which the command is directed. This occurs if the MPLS-TP section for the requested link is not satisfying an equal or higher priority switch request.
o 保護への手動切り替え（MS）：このコマンドは、コマンドが開始されたノードとコマンドが送信された隣接ノードとの間のリンクについて、動作エンティティから保護エンティティへの通常のトラフィックのリング切り替えを実行します。これは、要求されたリンクのMPLS-TPセクションが同等以上の優先順位のスイッチ要求を満たしていない場合に発生します。
o Exercise (EXER): This command exercises ring protection switching on the addressed link without completing the actual switch. The command is issued and the responses (RRs) are checked, but no normal traffic is affected.
o 演習（EXER）：このコマンドは、実際の切り替えを完了せずに、アドレス指定されたリンクでリング保護切り替えを実行します。コマンドが発行され、応答（RR）がチェックされますが、通常のトラフィックは影響を受けません。
The following commands are not transferred by the RPS message:
次のコマンドはRPSメッセージでは転送されません。
o Clear: This command clears the administrative command and WTR timer at the node to which the command was addressed. The node-to-node signaling after the removal of the externally initiated commands is performed using the NR code.
o クリア：このコマンドは、コマンドの宛先となったノードの管理コマンドとWTRタイマーをクリアします。外部で開始されたコマンドの削除後のノード間シグナリングは、NRコードを使用して実行されます。
o Lockout of Working (LW): This command prevents the normal traffic transported over the addressed link from being switched to the protection entity by disabling the node's capability of requesting a switch for this link in case of failure. If any normal traffic is already switched on the protection entity, the switch is dropped. If no other switch requests are active on the ring, the NR code is transmitted. This command has no impact on any other link. If the node receives the switch request from the adjacent node from any side, it will perform the requested switch. If the node receives the switch request addressed to the other node, it will enter the pass-through state.
o Lockout of Working（LW）：このコマンドは、障害が発生した場合に、このリンクの切り替えを要求するノードの機能を無効にすることにより、アドレス指定されたリンクを介して転送される通常のトラフィックが保護エンティティに切り替えられるのを防ぎます。保護エンティティで通常のトラフィックがすでに切り替えられている場合、スイッチはドロップされます。リング上でアクティブな他の切り替え要求がない場合、NRコードが送信されます。このコマンドは、他のリンクには影響を与えません。ノードは、隣接ノードからの切り替え要求をいずれかの側から受信すると、要求された切り替えを実行します。ノードが他のノードにアドレス指定された切り替え要求を受信すると、パススルー状態になります。
Automatically initiated commands can be initiated based on MPLS-TP section-layer OAM indication and the received switch requests.
自動的に開始されるコマンドは、MPLS-TPセクション層OAM表示と受信したスイッチ要求に基づいて開始できます。
The node can initiate the following switch requests automatically:
ノードは次の切り替え要求を自動的に開始できます。
o Signal Fail (SF): This command is issued when the MPLS-TP section-layer OAM detects a signal failure condition.
o 信号障害（SF）：このコマンドは、MPLS-TPセクション層OAMが信号障害状態を検出したときに発行されます。
o Wait-to-Restore (WTR): This command is issued when the MPLS-TP section detects that the SF condition has cleared. It is used to maintain the state during the WTR period unless it is preempted by a higher-priority switch request. The WTR time may be configured by the operator in 1 minute steps between 0 and 12 minutes; the default value is 5 minutes.
o 復元待ち（WTR）：このコマンドは、MPLS-TPセクションがSF条件がクリアされたことを検出したときに発行されます。優先度の高い切り替え要求によって横取りされない限り、WTR期間中の状態を維持するために使用されます。 WTR時間は、オペレーターが0〜12分の1分のステップで設定できます。デフォルト値は5分です。
o Reverse Request (RR): This command is transmitted to the source node of the received RPS message over the short path as an acknowledgment for receiving the switch request.
o リバース要求（RR）：このコマンドは、切り替え要求を受信したことの確認として、受信したRPSメッセージのソースノードにショートパスを介して送信されます。
This section describes the possible states of a ring node, the corresponding action of the working and protection ring tunnels on the node, and the RPS request that should be generated in that state.
このセクションでは、リングノードの考えられる状態、ノード上の現用リングトンネルと保護リングトンネルの対応するアクション、およびその状態で生成されるRPS要求について説明します。
+-----------------------------------+----------------+
| State | Signaled RPS |
+-----------------------------------+----------------+
| A | Idle | NR |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| B | Pass-through | N/A |
| | Working: no switch | |
| | Protection: pass-through | |
+-----+-----------------------------+----------------+
| C | Switching - LP | LP |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| D | Idle - LW | NR |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| E | Switching - FS | FS |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| F | Switching - SF | SF |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| G | Switching - MS | MS |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| H | Switching - WTR | WTR |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| I | Switching - EXER | EXER |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
In the state description below, 'O' means that a new local request will be rejected because of an existing request.
以下の状態の説明では、「O」は、既存の要求が原因で新しいローカル要求が拒否されることを意味します。
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP C (Switching - LP)
LW D (Idle - LW)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear N/A
WTR expires N/A
EXER I (Switching - EXER)
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP C (Switching - LP)
LW B (Pass-through)
FS O - if current state is due to
LP sent by another node
E (Switching - FS) - otherwise
SF O - if current state is due to
LP sent by another node
F (Switching - SF) - otherwise
Recover from SF N/A
MS O - if current state is due to
LP, SF, or FS sent by
another node
G (Switching - MS) - otherwise
Clear N/A
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP N/A
LW O
FS O
SF O
Recover from SF N/A
MS O
Clear A (Idle) - if there is no
failure in the ring
F (Switching - SF) - if there
is a failure at this node
B (Pass-through) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP)
LW N/A - if on the same link
D (Idle - LW) - if on another
link
FS O - if on the same link
E (Switching - FS) - if on
another link
SF O - if on the addressed link
F (Switching - SF) - if on
another link
Recover from SF N/A
MS O - if on the same link
G (Switching - MS) - if on
another link
Clear A (Idle) - if there is no
failure on addressed link
F (Switching - SF) - if there
is a failure on this link
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS N/A - if on the same link
E (Switching - FS) - if on
another link
SF O - if on the addressed link
E (Switching - FS) - if on
another link
Recover from SF N/A
MS O
Clear A (Idle) - if there is no
failure in the ring
F (Switching - SF) - if there
is a failure at this node
B (Pass-through) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS E (Switching - FS)
SF N/A - if on the same link
F (Switching - SF) - if on
another link
Recover from SF H (Switching - WTR)
MS O
Clear N/A
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS N/A - if on the same link
G (Switching - MS) - if on
another link, release the
switches but signal MS
Clear A
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP C (Switching - LP)
LW D (Idle - W)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear A
WTR expires A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP C (Switching - LP)
LW D (Idle - W)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear A
WTR expires N/A
EXER N/A - if on the same link
I (Switching - EXER)
=====================================================================
The priority of a remote request does not depend on the side from which the request is received.
リモート要求の優先順位は、要求の受信側には依存しません。
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR A (Idle)
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
E (Switching - FS) - otherwise
SF N/A - cannot happen when there
is an LP request in the
ring
F (Switching - SF) - otherwise
MS N/A - cannot happen when there
is an LP, FS, or SF
request in the ring
G (Switching - MS) - otherwise
WTR N/A - cannot happen when there
is an LP, FS, SF, or MS
request in the ring
EXER N/A - cannot happen when there
is an LP, FS, SF, MS, or
a WTR request in the
ring
I (Switching - EXER) -
otherwise
RR N/A
NR A (Idle) - if received from
both sides
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
SF N/A - cannot happen when there
is an LP request in the
ring
MS N/A - cannot happen when there
is an LP request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an LP request in the
ring
RR C (Switching - LP)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR D (Idle - LW)
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is an FS request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an FS request in the
ring
RR E (Switching - FS)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is an SF request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an SF request in the
ring
RR F (Switching - SF)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A
EXER N/A - cannot happen when there
is an MS request in the
ring
RR G (Switching - MS)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR H (Switching - WTR)
EXER N/A - cannot happen when there
is a WTR request in the
ring
RR H (Switching - WTR)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR I (Switching - EXER)
NR N/A
=====================================================================
5.3.5. State Transitions When Request Addresses to Another Node is Received
5.3.5. 別のノードへの要求アドレスを受信したときの状態遷移
The priority of a remote request does not depend on the side from which the request is received.
リモート要求の優先順位は、要求の受信側には依存しません。
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR B (Pass-through)
EXER B (Pass-through)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP B (Pass-through)
FS N/A - cannot happen when there
is an LP request in the
ring
B (Pass-through) - otherwise
SF N/A - cannot happen when there
is an LP request in the
ring
B (Pass-through) - otherwise
MS N/A - cannot happen when there
is an LP, FS, or SF
request in the ring
B (Pass-through) - otherwise
WTR N/A - cannot happen when there
is an LP, FS, SF, or MS
request in the ring
B (Pass-through) - otherwise
EXER N/A - cannot happen when there
is an LP, FS, SF, MS, or
a WTR request in the
ring
B (Pass-through) - otherwise
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
SF N/A - cannot happen when there
is an LP request in the
ring
MS N/A - cannot happen when there
is an LP request in the
ring
WTR N/A - cannot happen when there
is an LP request in the
ring
EXER N/A - cannot happen when there
is an LP request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR B (Pass-through)
EXER B (Pass-through)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP B (Pass-through)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is an FS request in the
ring
WTR N/A - cannot happen when there
is an FS request in the
ring
EXER N/A - cannot happen when there
is an FS request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP B (Pass-through)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is an SF request in the
ring
WTR N/A - cannot happen when there
is an SF request in the
ring
EXER N/A - cannot happen when there
is an SF request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A - cannot happen when there
is an MS request in the
ring
EXER N/A - cannot happen when there
is an MS request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR N/A
EXER N/A - cannot happen when there
is a WTR request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR N/A
=====================================================================
IANA has assigned the values listed in the sections below.
IANAは、以下のセクションにリストされている値を割り当てました。
The Channel Types for G-ACh are allocated from the PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586].
G-AChのチャネルタイプは、[RFC4446]で定義されたPW関連チャネルタイプレジストリから割り当てられ、[RFC5586]によって更新されます。
IANA has allocated the following new G-ACh Channel Type in the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry:
IANAは、「MPLS一般化関連チャネル（G-ACh）タイプ（疑似配線関連チャネルタイプを含む）」レジストリに次の新しいG-AChチャネルタイプを割り当てました。
Value | Description | Reference
-------+---------------------------------+--------------
0x002A | Ring Protection Switching (RPS) | this document
| Protocol |
-------+---------------------------------+--------------
IANA has created the subregistry "MPLS RPS Request Code Registry" under the "Generic Associated Channel (G-ACh) Parameters" registry. All code points within this registry shall be allocated according to the "Specification Required" procedure as specified in [RFC8126].
IANAは、「Generic Associated Channel（G-ACh）Parameters」レジストリの下にサブレジストリ「MPLS RPS Request Code Registry」を作成しました。このレジストリ内のすべてのコードポイントは、[RFC8126]で指定されている「Specification Required」の手順に従って割り当てられます。
The RPS request field is 8 bits; the allocated values are as follows:
RPS要求フィールドは8ビットです。割り当てられる値は次のとおりです。
Value Description Reference
------- --------------------------- -------------
0 No Request (NR) this document
1 Reverse Request (RR) this document
2 Unassigned
3 Exercise (EXER) this document
4 Unassigned
5 Wait-to-Restore (WTR) this document
6 Manual Switch (MS) this document
7-10 Unassigned
11 Signal Fail (SF) this document
12 Unassigned
13 Forced Switch (FS) this document
14 Unassigned
15 Lockout of Protection (LP) this document
16-254 Unassigned
255 Reserved
This document describes three protection modes of the RPS protocol. Operators could choose the appropriate protection mode according to their network and service requirement.
このドキュメントでは、RPSプロトコルの3つの保護モードについて説明します。オペレーターは、ネットワークとサービスの要件に応じて適切な保護モードを選択できます。
Wrapping mode provides a ring protection mechanism in which the protected traffic will reach every node of the ring and is applicable to protect both the point-to-point LSPs and LSPs that need to be dropped in several ring nodes, i.e., the point-to-multipoint applications. When protection is inactive, the protected traffic is switched (wrapped) to/from the protection ring tunnel at both sides of the defective link/node. Due to the wrapping, the additional propagation delay and bandwidth consumption of the protection tunnel are considerable. For bidirectional LSPs, the protected traffic in both directions is co-routed.
ラップモードは、保護されたトラフィックがリングのすべてのノードに到達するリング保護メカニズムを提供し、ポイントツーポイントLSPと、いくつかのリングノードでドロップする必要があるLSPの両方を保護するために適用できます。 -マルチポイントアプリケーション。保護が非アクティブの場合、保護されたトラフィックは、障害のあるリンク/ノードの両側の保護リングトンネルとの間で切り替えられます（ラップされます）。ラッピングが原因で、保護トンネルの追加の伝搬遅延と帯域幅の消費はかなりのものになります。双方向LSPの場合、両方向の保護されたトラフィックは同じ経路でルーティングされます。
Short-wrapping mode provides a ring protection mechanism that can be used to protect only point-to-point LSPs. When protection is inactive, the protected traffic is wrapped to the protection ring tunnel at the defective link/node and leaves the ring when the protection ring tunnel reaches the egress node. Compared with the wrapping mode, short-wrapping can reduce the propagation latency and bandwidth consumption of the protection tunnel. However, the two directions of a protected bidirectional LSP are not totally co-routed.
ショートラッピングモードは、ポイントツーポイントLSPのみを保護するために使用できるリング保護メカニズムを提供します。保護が非アクティブの場合、保護されたトラフィックは欠陥のあるリンク/ノードで保護リングトンネルにラップされ、保護リングトンネルが出力ノードに到達するとリングを離れます。ラッピングモードと比較して、ショートラッピングは、保護トンネルの伝搬遅延と帯域幅の消費を減らすことができます。ただし、保護された双方向LSPの2つの方向が完全に同じルートになるわけではありません。
Steering mode provides a ring protection mechanism that can be used to protect only point-to-point LSPs. When protection is inactive, the protected traffic is switched to the protection ring tunnel at the ingress node and leaves the ring when the protection ring tunnel reaches the egress node. The steering mode has the least propagation delay and bandwidth consumption of the three modes, and the two directions of a protected bidirectional LSP can be kept co-routed.
ステアリングモードは、ポイントツーポイントLSPのみを保護するために使用できるリング保護メカニズムを提供します。保護が非アクティブの場合、保護されたトラフィックは入力ノードで保護リングトンネルに切り替えられ、保護リングトンネルが出力ノードに到達するとリングを離れます。ステアリングモードは、3つのモードの中で最も伝播遅延と帯域幅の消費が少なく、保護された双方向LSPの2つの方向を同じ経路で維持できます。
Note that only one protection mode can be provisioned in the whole ring for all protected traffic.
すべての保護されたトラフィックに対して、リング全体でプロビジョニングできる保護モードは1つだけであることに注意してください。
MPLS-TP is a subset of MPLS, thus it builds upon many of the aspects of the security model of MPLS. Please refer to [RFC5920] for generic MPLS security issues and methods for securing traffic privacy and integrity.
MPLS-TPはMPLSのサブセットであるため、MPLSのセキュリティモデルの多くの側面に基づいています。トラフィックのプライバシーと整合性を保護するための一般的なMPLSセキュリティの問題と方法については、[RFC5920]を参照してください。
The RPS message defined in this document is used for protection coordination on the ring; if it is injected or modified by an attacker, the ring nodes might not agree on the protection action, and the improper protection-switching action may cause a temporary break to services traversing the ring. It is important that the RPS message is used within a trusted MPLS-TP network domain as described in [RFC6941].
このドキュメントで定義されているRPSメッセージは、リングでの保護調整に使用されます。攻撃者によって挿入または変更された場合、リングノードは保護アクションに同意しない可能性があり、不適切な保護切り替えアクションは、リングを通過するサービスに一時的な中断を引き起こす可能性があります。 [RFC6941]で説明されているように、RPSメッセージが信頼できるMPLS-TPネットワークドメイン内で使用されることが重要です。
The RPS message is carried in the G-ACh [RFC5586], so it is dependent on the security of the G-ACh itself. The G-ACh is a generalization of the Associated Channel defined in [RFC4385]. Thus, this document relies on the security mechanisms provided for the Associated Channel as described in those two documents.
RPSメッセージはG-ACh [RFC5586]で伝送されるため、G-ACh自体のセキュリティに依存しています。 G-AChは、[RFC4385]で定義されている関連チャネルの一般化です。したがって、このドキュメントは、これらの2つのドキュメントで説明されているように、関連チャネルに提供されるセキュリティメカニズムに依存しています。
As described in the security considerations of [RFC6378], the G-ACh is essentially connection oriented, so injection or modification of control messages requires the subversion of a transit node. Such subversion is generally considered hard in connection-oriented MPLS networks and impossible to protect against at the protocol level. Management-level techniques are more appropriate. The procedures and protocol extensions defined in this document do not affect the security model of MPLS-TP linear protection as defined in [RFC6378].
[RFC6378]のセキュリティに関する考慮事項で説明されているように、G-AChは基本的に接続指向であるため、制御メッセージの挿入または変更にはトランジットノードの破壊が必要です。このような転覆は、一般に、接続指向のMPLSネットワークでは困難であると見なされており、プロトコルレベルで保護することは不可能です。管理レベルの手法がより適切です。このドキュメントで定義されている手順とプロトコル拡張は、[RFC6378]で定義されているMPLS-TP線形保護のセキュリティモデルに影響を与えません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、DOI 10.17487 / RFC4385、2006年2月、<https://www.rfc-editor.org/info/rfc4385>。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANA割り当て」、BCP 116、RFC 4446、DOI 10.17487 / RFC4446、2006年4月、<https://www.rfc-editor.org/info / rfc4446>。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC5586] Bocci、M。、編、Vigoureux、M、編、およびS. Bryant、編、「MPLS Generic Associated Channel」、RFC 5586、DOI 10.17487 / RFC5586、2009年6月、<https：// www.rfc-editor.org/info/rfc5586>。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、DOI 10.17487 / RFC5654、2009年9月、<https://www.rfc-editor.org/info/rfc5654>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6371] Busi、I.、Ed。およびD. Allan編、「MPLSベースのトランスポートネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、DOI 10.17487 / RFC6371、2011年9月、<https://www.rfc-editor.org/info/ rfc6371>。
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <https://www.rfc-editor.org/info/rfc6378>.
[RFC6378] Weingarten、Y。、編、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、編、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、 DOI 10.17487 / RFC6378、2011年10月、<https://www.rfc-editor.org/info/rfc6378>。
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013, <https://www.rfc-editor.org/info/rfc6941>.
[RFC6941] Fang、L.、Ed。、Niven-Jenkins、B.、Ed。、Mansfield、S.、Ed。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、DOI 10.17487 / RFC6941、2013年4月、<https://www.rfc-editor.org/info/rfc6941>。
[RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., Fondelli, F., Corsi, M., Wu, B., and X. Dai, "Applicability of MPLS Transport Profile for Ring Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, <https://www.rfc-editor.org/info/rfc6974>.
[RFC6974] Weingarten、Y.、Bryant、S.、Ceccarelli、D.、Caviglia、D.、Fondelli、F.、Corsi、M.、Wu、B。、およびX. Dai、「MPLSトランスポートプロファイルの適用性リングトポロジ」、RFC 6974、DOI 10.17487 / RFC6974、2013年7月、<https://www.rfc-editor.org/info/rfc6974>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgements
謝辞
The authors would like to thank Gregory Mirsky, Yimin Shen, Eric Osborne, Spencer Jackson, and Eric Gray for their valuable comments and suggestions.
著者は、貴重なコメントと提案をしてくれたGregory Mirsky、Yimin Shen、Eric Osborne、Spencer Jackson、Eric Greyに感謝します。
Contributors
貢献者
The following people contributed significantly to the content of this document and should be considered co-authors:
次の人々はこの文書の内容に大きく貢献し、共著者と見なされるべきです：
Kai Liu Huawei Technologies Email: alex.liukai@huawei.com
かい ぃう ふあうぇい てｃｈのぉぎえｓ えまいｌ： あぇｘ。ぃうかい＠ふあうぇい。こｍ
Jia He Huawei Technologies Email: hejia@huawei.com
J IA heh UAはテクノロジーメールです：合家@武汉.com
Fang Li China Academy of Telecommunication Research MIIT China Email: lifang@catr.cn
Fang Li China通信研究アカデミーMIIT中国Eメール：lifang@catr.cn
Jian Yang ZTE Corporation China Email: yang.jian90@zte.com.cn
J Ian yang ZT E企業中国のメール：Yang。90 @中特.comを参照してください。
Junfang Wang Fiberhome Telecommunication Technologies Co., LTD. Email: wjf@fiberhome.com.cn
Jun Fang Wangファイバーホームテレコミュニケーションテクノロジーズ株式会社Eメール：Calculus @ fiber home.com。
Wen Ye China Mobile Email: yewen@chinamobile.com
wen Y E China Mobileメール：Ye Wen @ China Mobile.com
Minxue Wang China Mobile Email: wangminxue@chinamobile.com
Minxue Wang Chinaモバイルメール：wangminxue@chinamobile.com
Sheng Liu China Mobile Email: liusheng@chinamobile.com
SはGL IU China Mobileのメールです：Liu Sheng @ China Mobile.com
Guanghui Sun Huawei Technologies Email: sunguanghui@huawei.com
GUケースG会議sun hu Aはテクノロジーのメールです：Sun Guanghui@Huawei.com
Authors' Addresses
著者のアドレス
Weiqiang Cheng China Mobile
魏強成中国モバイル
Email: chengweiqiang@chinamobile.com
Lei Wang China Mobile
レイワンチャイナモバイル
Email: wangleiyj@chinamobile.com
Han Li China Mobile
はん ぃ ちな もびぇ
Email: lihan@chinamobile.com
Huub van Helvoort Hai Gaoming BV
Huub van Helvoort Hai Gaoming BV
Email: huubatwork@gmail.com
Jie Dong Huawei Technologies
J IEドンフーAはテクノロジー
Email: jie.dong@huawei.com