[要約] 要約： RFC 7271は、MPLS-TP（MPLS Transport Profile）線形保護の運用期待に合わせるためのSDH、OTN、およびEthernetトランスポートネットワークオペレーターの要件を定義しています。目的： このRFCの目的は、MPLS-TP線形保護の運用要件を明確にし、SDH、OTN、およびEthernetトランスポートネットワークオペレーターが期待する動作を満たすためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) J. Ryoo, Ed.
Request for Comments: 7271 ETRI
Updates: 6378 E. Gray, Ed.
Category: Standards Track Ericsson
ISSN: 2070-1721 H. van Helvoort
Huawei Technologies
A. D'Alessandro
Telecom Italia
T. Cheung
ETRI
E. Osborne
June 2014
MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators
MPLSトランスポートプロファイル（MPLS-TP）線形保護により、同期デジタル階層、光トランスポートネットワーク、およびイーサネットトランスポートネットワークオペレーターの運用上の期待に対応
Abstract
概要
This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.
このドキュメントでは、RFC 6378で定義されているMPLSトランスポートプロファイル（MPLS-TP）線形保護の一部の機能を実行するための代替メカニズムについて説明し、追加のメカニズムも定義しています。これらの代替および追加のメカニズムの目的は、他のトランスポートネットワークで見られる線形保護の動作をより厳密にモデル化するオペレーター制御とエクスペリエンスを提供することです。
This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.
このドキュメントでは、線形保護の機能とモードも紹介しています。機能は個々の動作であり、モードは機能の特定の組み合わせです。このドキュメントでは、保護状態調整（PSC）モードと自動保護切り替え（APS）モードの2つのモードが定義されています。
This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.
このドキュメントでは、APSモードに関連付けられているすべての機能が有効になっている場合の優先度ロジックとステートマシンを含むPSCプロトコルの動作について説明します。
This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.
このドキュメントは、RFC 6378を更新します。ここで定義されている機能通知メソッドは、そのドキュメントへの追加です。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc7271.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7271で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Capability 1: Priority Modification . . . . . . . . . . . . . 6
4.1. Motivation for Swapping Priorities of FS and SF-P . . . . 6
4.2. Motivation for Raising the Priority of SFc . . . . . . . 7
4.3. Motivation for Introducing the Freeze Command . . . . . . 7
4.4. Procedures in Support of Priority Modification . . . . . 8
5. Capability 2: Non-revertive Behavior Modification . . . . . . 8
6. Capability 3: Support of the MS-W Command . . . . . . . . . . 8
6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8
6.2. Terminology to Support MS-W . . . . . . . . . . . . . . . 9
6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9
6.4. Equal-Priority Resolution for MS . . . . . . . . . . . . 10
7. Capability 4: Support of Protection against SD . . . . . . . 10
7.1. Motivation for Supporting Protection against SD . . . . . 10
7.2. Terminology to Support SD . . . . . . . . . . . . . . . . 10
7.3. Behavior of Protection against SD . . . . . . . . . . . . 11
7.4. Equal-Priority Resolution . . . . . . . . . . . . . . . . 12
8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13
9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14
9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Sending and Receiving the Capabilities TLV . . . . . 15
9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . 16
9.2.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . 16
10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 17
10.1. Request Field in PSC Protocol Message . . . . . . . . . 17
10.2. Priorities of Local Inputs and Remote Requests . . . . . 17
10.2.1. Equal-Priority Requests . . . . . . . . . . . . . . 18
10.3. Acceptance and Retention of Local Inputs . . . . . . . . 20
11. State Transition Tables in APS Mode . . . . . . . . . . . . . 20
11.1. State Transition by Local Inputs . . . . . . . . . . . . 23
11.2. State Transition by Remote Messages . . . . . . . . . . 25
11.3. State Transition for 1+1 Unidirectional Protection . . . 27
12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 29
14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 29
14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 29
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. An Example of an Out-of-Service Scenario . . . . . . 32
Appendix B. An Example of a Sequence Diagram Showing
the Problem with the Priority Level of SFc . . . . . 33
Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 34
Appendix D. Operation Examples of the APS Mode . . . . . . . . . 35
Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) are described in RFC 6378 [RFC6378] to meet the requirements described in RFC 5654 [RFC5654].
MPLSトランスポートプロファイル（MPLS-TP）の線形保護メカニズムは、RFC 5654 [RFC5654]で説明されている要件を満たすために、RFC 6378 [RFC6378]で説明されています。
This document describes alternate mechanisms to perform some of the functions of linear protection, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks, such as Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), and Ethernet transport networks. Linear protection for SDH, OTN, and Ethernet transport networks is defined in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1], and G.8031 [G8031], respectively.
このドキュメントでは、線形保護の一部の機能を実行するための代替メカニズムについて説明し、追加のメカニズムも定義します。これらの代替および追加のメカニズムの目的は、同期デジタル階層（SDH）、光トランスポートネットワーク（OTN）、イーサネットトランスポートネットワークなどの他のトランスポートネットワークで見られる線形保護の動作をより厳密にモデル化するオペレーター制御とエクスペリエンスを提供することです。 SDH、OTN、およびイーサネットトランスポートネットワークの線形保護は、ITU-T勧告G.841 [G841]、G.873.1 [G873.1]、およびG.8031 [G8031]でそれぞれ定義されています。
The reader of this document is assumed to be familiar with [RFC6378].
このドキュメントの読者は、[RFC6378]に精通していることを前提としています。
The alternative mechanisms described in this document are for the following capabilities:
このドキュメントで説明する代替メカニズムは、次の機能のためのものです。
1. Priority modification,
1. 優先度の変更、
2. non-revertive behavior modification,
2. 非リバーティブな動作の変更、
and the following capabilities have been added to define additional mechanisms:
追加のメカニズムを定義するために、次の機能が追加されました。
3. support of the Manual Switch to Working path (MS-W) command,
3. 作業パスへの手動切り替え（MS-W）コマンドのサポート
4. support of protection against Signal Degrade (SD), and
4. 信号劣化（SD）に対する保護のサポート、および
5. support of the Exercise (EXER) command.
5. エクササイズ（EXER）コマンドのサポート。
The priority modification includes raising the priority of Signal Fail on Protection path (SF-P) relative to Forced Switch (FS), and raising the priority level of Clear Signal Fail (SFc) above SF-P.
優先順位の変更には、強制切り替え（FS）に比べて保護パス（SF-P）での信号障害の優先順位を上げること、およびSF-Pを超えるクリア信号障害（SFc）の優先順位レベルを上げることが含まれます。
Non-revertive behavior is modified to align with the behavior defined in RFC 4427 [RFC4427] as well as to follow the behavior of linear protection seen in other transport networks.
非リバーティブ動作は、RFC 4427 [RFC4427]で定義された動作に合わせて変更され、他のトランスポートネットワークで見られる線形保護の動作に従うように変更されています。
Support of the MS-W command to revert traffic to the working path in non-revertive operation is covered in this document.
このドキュメントでは、非リバーティブ操作でトラフィックを現用パスに戻すMS-Wコマンドのサポートについて説明します。
Support of the protection-switching protocol against SD is covered in this document. The specifics for the method of identifying SD are out of the scope for this document and are treated similarly to Signal Fail (SF) in [RFC6378].
このドキュメントでは、SDに対する保護切り替えプロトコルのサポートについて説明します。 SDを識別する方法の詳細は、このドキュメントの範囲外であり、[RFC6378]のSignal Fail（SF）と同様に扱われます。
Support of the EXER command to test if the Protection State Coordination (PSC) communication is operating correctly is also covered in this document. Without actually switching traffic, the EXER command tests and validates the linear protection mechanism and PSC protocol including the aliveness of the priority logic, the PSC state machine, the PSC message generation and reception, and the integrity of the protection path.
保護状態調整（PSC）通信が正しく動作しているかどうかをテストするためのEXERコマンドのサポートについても、このドキュメントで説明しています。 EXERコマンドは、実際にトラフィックを切り替えずに、優先保護ロジック、PSCステートマシン、PSCメッセージの生成と受信、および保護パスの整合性の有効性を含む線形保護メカニズムとPSCプロトコルをテストおよび検証します。
This document introduces capabilities and modes. A capability is an individual behavior. The capabilities of a node are advertised using the method given in this document. A mode is a particular combination of capabilities. Two modes are defined in this document: PSC mode and Automatic Protection Switching (APS) mode.
このドキュメントでは、機能とモードを紹介します。能力は個人の行動です。ノードの機能は、このドキュメントに記載されている方法を使用してアドバタイズされます。モードは、機能の特定の組み合わせです。このドキュメントでは、PSCモードと自動保護切り替え（APS）モードの2つのモードが定義されています。
Other modes may be defined as new combinations of the capabilities defined in this document or through the definition of additional capabilities. In either case, the specification defining a new mode will be responsible for documenting the behavior, the priority logic, and the state machine of the PSC protocol when the set of capabilities in the new mode is enabled.
他のモードは、このドキュメントで定義されている機能の新しい組み合わせとして、または追加機能の定義を通じて定義できます。どちらの場合でも、新しいモードの機能のセットが有効になっている場合、新しいモードを定義する仕様は、PSCプロトコルの動作、優先度ロジック、およびステートマシンを文書化する責任があります。
This document describes the behavior, the priority logic, and the state machine of the PSC protocol when all the capabilities associated with the APS mode are enabled. The PSC protocol behavior for the PSC mode is as defined in [RFC6378].
このドキュメントでは、APSモードに関連するすべての機能が有効になっている場合のPSCプロトコルの動作、優先度ロジック、およびステートマシンについて説明します。 PSCモードのPSCプロトコルの動作は、[RFC6378]で定義されています。
This document updates [RFC6378] by adding a capability advertisement mechanism. It is recommended that existing implementations of the PSC protocol be updated to support this capability. Backward compatibility with existing implementations that do not support this mechanism is described in Section 9.2.1.
このドキュメントは、機能通知メカニズムを追加することによって[RFC6378]を更新します。この機能をサポートするために、PSCプロトコルの既存の実装を更新することをお勧めします。このメカニズムをサポートしない既存の実装との下位互換性については、9.2.1項で説明しています。
Implementations are expected to be configured to support a specific set of capabilities (a mode) and to reject messages that indicate the use of a different set of capabilities (a different mode). Thus, the capability advertisement is not a negotiation but a verification that peers are using the same mode.
実装は、特定の機能セット（モード）をサポートし、異なる機能セット（異なるモード）の使用を示すメッセージを拒否するように構成されていることが期待されます。したがって、機能の通知はネゴシエーションではなく、ピアが同じモードを使用していることの確認です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
APS Automatic Protection Switching DNR Do-not-Revert EXER Exercise FS Forced Switch LO Lockout of protection MS Manual Switch MS-P Manual Switch to Protection path MS-W Manual Switch to Working path MPLS-TP MPLS Transport Profile NR No Request OC Operator Clear OTN Optical Transport Network PSC Protection State Coordination RR Reverse Request SD Signal Degrade SD-P Signal Degrade on Protection path SD-W Signal Degrade on Working path SDH Synchronous Digital Hierarchy SF Signal Fail SF-P Signal Fail on Protection path SF-W Signal Fail on Working path SFc Clear Signal Fail SFDc Clear Signal Fail or Degrade WTR Wait-to-Restore
APS自動保護切り替えDNR Do-not-Revert EXER演習FS強制切り替えLO保護のロックアウトMS手動切り替えMS-P手動切り替えから保護パスへMS-W手動切り替えから現用パスへMPLS-TP MPLSトランスポートプロファイルNR要求なしOCオペレータークリアOTN光伝送ネットワークPSC保護状態の調整RR逆要求SD信号の劣化SD-P信号の保護パスでの劣化SD-W信号の現用パスでの劣化SDH同期デジタル階層SF信号の障害SF-P信号の障害保護パスでのSF-W信号の障害作業パス上でSFc信号のクリアの失敗SFDc信号のクリアの失敗または低下WTR復元待ち
[RFC6378] defines the priority of FS to be higher than that of SF-P. That document also defines the priority of Clear SF (SFc) to be low. This document defines the priority modification capability whereby the relative priorities of FS and SF-P are swapped, and the priority of Clear SF (SFc) is raised. In addition, this capability introduces the Freeze command as described in Appendix C. The rationale for these changes is detailed in the following subsections from both the technical and network operational aspects.
[RFC6378]は、FSの優先度をSF-Pの優先度より高く定義しています。その文書はまた、クリアSF（SFc）の優先度を低く定義しています。このドキュメントでは、FSとSF-Pの相対的な優先順位が交換され、Clear SF（SFc）の優先順位が上げられる優先度変更機能を定義しています。さらに、この機能により、付録Cで説明されているようにFreezeコマンドが導入されます。これらの変更の根拠は、技術面とネットワーク運用面の両方から、以下のサブセクションで詳しく説明されています。
Defining the priority of FS higher than that of SF-P can result in a situation where the protected traffic is taken out of service. When the protection path fails, PSC communication may stop as a result. In this case, if any input that is supposed to be signaled to the other end has a higher priority than SF-P, then this can result in an unpredictable protection-switching state. An example scenario that may result in an out-of-service situation is presented in Appendix A of this document.
FSの優先度をSF-Pの優先度よりも高く定義すると、保護されたトラフィックがサービスを停止する場合があります。保護パスに障害が発生すると、結果としてPSC通信が停止する場合があります。この場合、もう一方の端に信号が送られることになっている入力の優先順位がSF-Pよりも高いと、予測できない保護切り替え状態になる可能性があります。アウトオブサービス状態になる可能性のあるシナリオの例は、このドキュメントの付録Aに記載されています。
According to Section 2.4 of [RFC5654], it MUST be possible to operate an MPLS-TP network without using a control plane. This means that the PSC communication channel is very important for the transfer of external switching commands (e.g., FS), and these commands should not rely on the presence of a control plane. In consequence, the failure of the PSC communication channel has higher priority than FS.
[RFC5654]のセクション2.4によると、コントロールプレーンを使用せずにMPLS-TPネットワークを運用できる必要があります。これは、PSC通信チャネルが外部切り替えコマンド（FSなど）の転送にとって非常に重要であり、これらのコマンドがコントロールプレーンの存在に依存してはならないことを意味します。その結果、PSC通信チャネルの障害はFSよりも優先度が高くなります。
In other transport networks (such as SDH, OTN, and Ethernet transport networks), the priority of SF-P has been higher than that of FS. It is therefore important to offer network operators the option of having the same behavior in their MPLS-TP networks so that they can have the same operational protection-switching behavior to which they have become accustomed. Typically, an FS command is issued before network maintenance jobs (e.g., replacing optical cables or other network components). When an operator pulls out a cable on the protection path, by mistake, the traffic should continue to be protected, and the operator expects this behavior based on his/her experience with traditional transport network operations.
他のトランスポートネットワーク（SDH、OTN、イーサネットトランスポートネットワークなど）では、SF-Pの優先度がFSよりも高くなっています。したがって、ネットワークオペレータがMPLS-TPネットワークで同じ動作をするオプションを提供して、慣れ親しんだ動作保護スイッチング動作と同じになるようにすることが重要です。通常、FSコマンドは、ネットワークメンテナンスジョブ（光ケーブルやその他のネットワークコンポーネントの交換など）の前に発行されます。オペレーターが誤って保護パス上のケーブルを引き抜いた場合、トラフィックは引き続き保護されるべきであり、オペレーターは従来のトランスポートネットワーク操作の経験に基づいてこの動作を期待します。
The priority level of SFc defined in [RFC6378] can cause traffic disruption when a node that has experienced local signal fails on both the working and the protection paths is recovering from these failures.
[RFC6378]で定義されているSFcの優先度レベルは、ローカル信号を経験したノードが現用パスと保護パスの両方でこれらの障害から回復しているときに、トラフィックの中断を引き起こす可能性があります。
A sequence diagram highlighting the problem with the priority level of SFc as defined in [RFC6378] is presented in Appendix B.
[RFC6378]で定義されているSFcの優先度レベルの問題を強調するシーケンス図を付録Bに示します。
With the priority swapping between FS and SF-P, the traffic is always moved back to the working path when SF-P occurs in Protecting Administrative state. In case network operators need an option to control their networks so that the traffic can remain on the protection path even when the PSC communication channel is broken, the Freeze command can be used. Freeze is defined to be a "local" command that is not signaled to the remote node. The use of the Freeze command is described in Appendix C.
FSとSF-P間の優先順位スワッピングにより、SF-PがProtecting Administrative状態で発生すると、トラフィックは常に現用パスに戻されます。ネットワークオペレーターがネットワークを制御するオプションが必要な場合は、PSC通信チャネルが切断された場合でもトラフィックを保護パスに残すことができるため、Freezeコマンドを使用できます。フリーズは、リモートノードに通知されない「ローカル」コマンドであると定義されています。 Freezeコマンドの使用については、付録Cで説明しています。
When the modified priority order specified in this document is in use, the list of local requests in order of priority SHALL be as follows (from highest to lowest):
このドキュメントで指定された変更された優先順位が使用されている場合、優先順位の順序でのローカル要求のリストは次のようになります（最高から最低まで）。
o Clear Signal Fail
o クリア信号失敗
o Signal Fail on Protection path
o 保護パスの信号障害
o Forced Switch
o 強制切り替え
o Signal Fail on Working path
o 現用パスの信号障害
This requires modification of the PSC Control Logic (including the state machine) relative to that described in [RFC6378]. Sections 10 and 11 present the PSC Control Logic when all capabilities of APS mode are enabled.
これには、[RFC6378]で説明されているPSC制御ロジック（ステートマシンを含む）の変更が必要です。セクション10と11は、APSモードのすべての機能が有効な場合のPSC制御ロジックを示しています。
Non-revertive operation of protection switching is defined in [RFC4427]. In this operation, the traffic does not return to the working path when switch-over requests are terminated.
保護切り替えの非リバーティブ動作は、[RFC4427]で定義されています。この操作では、切り替え要求が終了してもトラフィックは現用パスに戻りません。
However, the PSC protocol defined in [RFC6378] supports this operation only when recovering from a defect condition: it does not support the non-revertive function when an operator's switch-over command, such as FS or Manual Switch (MS), is cleared. To be aligned with the behavior in other transport networks and to be consistent with [RFC4427], a node should go into the Do-not-Revert (DNR) state not only when a failure condition on the working path is cleared, but also when an operator command that requested switch-over is cleared.
ただし、[RFC6378]で定義されているPSCプロトコルは、障害状態からの回復時にのみこの操作をサポートします。FSや手動切り替え（MS）などのオペレーターの切り替えコマンドがクリアされている場合、非復元機能はサポートされません。 。他のトランスポートネットワークの動作に合わせて[RFC4427]と整合させるには、現用パスの障害状態がクリアされたときだけでなく、ノードがDo-not-Revert（DNR）状態になる必要があります。切り替えを要求したオペレーターコマンドはクリアされます。
This requires modification to the PSC Control Logic (including the state machine) relative to that described in [RFC6378]. Sections 10 and 11 present the PSC Control Logic when all capabilities of APS mode are enabled.
これには、[RFC6378]で説明されているものと比較して、PSC制御ロジック（ステートマシンを含む）を変更する必要があります。セクション10と11は、APSモードのすべての機能が有効な場合のPSC制御ロジックを示しています。
Changing the non-revertive operation as described in Section 5 introduces the necessity of a new operator command to revert traffic to the working path in the DNR state. When the traffic is on the protection path in the DNR state, a Manual Switch to Working (MS-W) command is issued to switch the normal traffic back to the working path. According to Section 4.3.3.6 (Do-not-Revert State) in [RFC6378], "To revert back to the Normal state, the administrator SHALL issue a Lockout of protection command followed by a Clear command." However, using the Lockout of protection (LO) command introduces the potential risk of an unprotected situation while the LO is in effect.
セクション5で説明されているように非リバーティブ操作を変更すると、DNR状態の現用パスにトラフィックを戻すための新しいオペレーターコマンドが必要になります。トラフィックがDNR状態の保護パス上にある場合、通常のトラフィックを現用パスに切り替えるために、手動切り替え（MS-W）コマンドが発行されます。 [RFC6378]のセクション4.3.3.6（Do-not-Revert State）によると、「通常の状態に戻すには、管理者は保護コマンドのロックアウトとそれに続くクリアコマンドを発行する必要があります（SHALL）」。ただし、保護のロックアウト（LO）コマンドを使用すると、LOが有効な間、保護されていない状況の潜在的なリスクが生じます。
The "Manual switch-over for recovery LSP/span" command is defined in [RFC4427]. Requirement 83 in [RFC5654] states that the external commands defined in [RFC4427] MUST be supported. Since there is no support for this external command in [RFC6378], this functionality should be added to PSC. This support is provided by introducing the MS-W command. The MS-W command, as described here, corresponds to the "Manual switch-over for recovery LSP/span" command.
「回復LSP /スパンのための手動スイッチオーバー」コマンドは[RFC4427]で定義されています。 [RFC5654]の要件83は、[RFC4427]で定義された外部コマンドをサポートする必要があることを述べています。 [RFC6378]ではこの外部コマンドはサポートされていないため、この機能をPSCに追加する必要があります。このサポートは、MS-Wコマンドの導入によって提供されます。ここで説明するMS-Wコマンドは、「回復LSP /スパンの手動切り替え」コマンドに対応しています。
[RFC6378] uses the term "Manual Switch" and its acronym "MS". This document uses the term "Manual Switch to Protection path" and "MS-P" to have the same meaning, while avoiding confusion with "Manual Switch to Working path" and its acronym "MS-W".
[RFC6378]は、「Manual Switch」という用語とその頭字語「MS」を使用しています。このドキュメントでは、「Manual Switch to Protection path」と「MS-P」という用語を同じ意味で使用し、「Manual Switch to Working path」とその頭字語「MS-W」との混同を避けています。
Similarly, we modify the name of "Protecting Administrative" state (as defined in [RFC6378]) to be "Switching Administrative" state to include the case where traffic is switched to the working path as a result of the external MS-W command.
同様に、[Protecting Administrative]状態（[RFC6378]で定義）の名前を "Switching Administrative"状態に変更して、外部MS-Wコマンドの結果としてトラフィックが現用パスに切り替えられた場合を含めます。
MS-P and MS-W SHALL have the same priority. We consider different instances of determining the priority of the commands when they are received either in succession or simultaneously.
MS-PとMS-Wは同じ優先順位を持つ必要があります。コマンドが連続してまたは同時に受信されたときに、コマンドの優先順位を決定するさまざまなインスタンスを検討します。
o When two commands are received in succession, the command that is received after the initial command SHALL be cancelled.
o 2つのコマンドが連続して受信された場合、最初のコマンドの後に受信されたコマンドはキャンセルされます。
o If two nodes simultaneously receive commands that indicate opposite operations (i.e., one node receives MS-P and the other node receives MS-W) and transmit the indications to the remote node, the MS-W SHALL be considered to have a higher priority, and the MS-P SHALL be cancelled and discarded.
o 2つのノードが同時に反対の操作を示すコマンドを受信し（つまり、一方のノードがMS-Pを受信し、もう一方のノードがMS-Wを受信する）、その指示をリモートノードに送信する場合、MS-Wは優先度が高いと見なす必要があります。また、MS-Pはキャンセルして破棄する必要があります。
Two commands, MS-P and MS-W, are transmitted using the same Request field value but SHALL indicate in the Fault Path (FPath) value the path from which the traffic is being diverted. When traffic is switched to the protection path, the FPath field value SHALL be set to 1, indicating that traffic is being diverted from the working path. When traffic is switched to the working path, the FPath field value SHALL be set to 0, indicating that traffic is being diverted from the protection path. The Data Path (Path) field SHALL indicate where user data traffic is being transported (i.e., if the working path is selected, then Path is set to 0; if the protection path is selected, then Path is set to 1).
2つのコマンドMS-PとMS-Wは、同じリクエストフィールド値を使用して送信されますが、フォールトパス（FPath）値で、トラフィックの迂回元のパスを示す必要があります。トラフィックが保護パスに切り替えられると、FPathフィールドの値が1に設定されて（SHALL）、トラフィックが現用パスから迂回されていることを示します。トラフィックが現用パスに切り替えられると、FPathフィールドの値は0に設定されて（SHALL）、トラフィックが保護パスから迂回されていることを示します。データパス（パス）フィールドは、ユーザーデータトラフィックが転送される場所を示します（つまり、現用パスが選択されている場合、パスは0に設定されます。保護パスが選択されている場合、パスは1に設定されます）。
When an MS command is in effect at a node, any subsequent MS or EXER command and any other lower-priority requests SHALL be ignored.
MSコマンドがノードで有効な場合、後続のMSまたはEXERコマンドおよびその他の優先度の低い要求はすべて無視されます（SHALL）。
[RFC6378] defines only one rule for the equal-priority condition in Section 4.3.2 as "The remote message from the far-end LER is assigned a priority just below the similar local input." In order to support the Manual Switch behavior described in Section 6.3, additional rules for equal-priority resolution are required. Since the support of protection against signal degrade also requires a similar equal-priority resolution, the rules are described in Section 7.4.
[RFC6378]は、セクション4.3.2で、同等の優先順位の条件に対して「遠端のLERからのリモートメッセージには、同様のローカル入力のすぐ下に優先順位が割り当てられる」と定義しています。セクション6.3で説明されている手動切り替えの動作をサポートするには、同じ優先順位の解決のための追加のルールが必要です。信号劣化に対する保護のサポートも同様の優先度の解決が必要であるため、ルールについては7.4節で説明します。
Support of this function requires changes to the PSC Control Logic (including the state machine) relative to that shown in [RFC6378]. Sections 10 and 11 present the PSC Control Logic when all capabilities of APS mode are enabled.
この機能をサポートするには、[RFC6378]に示されているものと比較して、PSC制御ロジック（ステートマシンを含む）を変更する必要があります。セクション10と11は、APSモードのすべての機能が有効な場合のPSC制御ロジックを示しています。
In the MPLS-TP Survivability Framework [RFC6372], both SF and SD fault conditions can be used to trigger protection switching.
MPLS-TP存続可能性フレームワーク[RFC6372]では、SFとSDの両方の障害状態を使用して、保護切り替えをトリガーできます。
[RFC6378], which defines the protection-switching protocol for MPLS-TP, does not specify how the SF and SD are detected, and specifies the protection-switching protocol associated with SF only.
MPLS-TPの保護切り替えプロトコルを定義する[RFC6378]は、SFとSDの検出方法を指定せず、SFのみに関連付けられた保護切り替えプロトコルを指定します。
The PSC protocol associated with SD is covered in this document, but the specifics for the method of identifying SD is out of scope for the protection protocol in the same way that SF detection and MS or FS command initiation are out of scope.
SDに関連付けられたPSCプロトコルはこのドキュメントで説明されていますが、SDを識別する方法の詳細は、SF検出とMSまたはFSコマンドの開始が範囲外であるのと同じ方法で、保護プロトコルの範囲外です。
In this document, the term Clear Signal Fail or Degrade (SFDc) is used to indicate the clearance of either a degraded condition or a failure condition.
このドキュメントでは、信号の障害または劣化のクリア（SFDc）という用語は、劣化状態または障害状態のクリアランスを示すために使用されます。
The second paragraph of Section 4.3.3.2 (Unavailable State) in [RFC6378] shows the intention of including Signal Degrade on Protection path (SD-P) in the Unavailable state. Even though the protection path can be partially available under the condition of SD-P, this document follows the same state grouping as [RFC6378] for SD-P.
[RFC6378]のセクション4.3.3.2（使用不可状態）の2番目の段落は、保護パス（SD-P）に信号劣化を使用不可状態に含める意図を示しています。 SD-Pの条件下では保護パスが部分的に利用できる場合がありますが、このドキュメントでは、SD-Pの[RFC6378]と同じ状態グループに従っています。
The bulleted item on the Protecting Failure state in Section 3.6 of [RFC6378] includes the degraded condition in the Protecting Failure state. This document follows the same state grouping as [RFC6378] for Signal Degrade on Working path (SD-W).
[RFC6378]のセクション3.6の保護障害状態に関する箇条書きの項目には、保護障害状態の機能低下状態が含まれています。このドキュメントは、[RFC6378]と同じ状態のグループに従って、現用パスの信号劣化（SD-W）を追跡します。
To better align the behavior of MPLS-TP networks with that of other transport networks (such as SDH, OTN, and Ethernet transport networks), we define the following:
MPLS-TPネットワークの動作を他のトランスポートネットワーク（SDH、OTN、イーサネットトランスポートネットワークなど）の動作に合わせるために、以下を定義します。
o The priorities of SD-P and SD-W SHALL be equal.
o SD-PとSD-Wの優先順位は同じである必要があります。
o Once a switch has been completed due to SD on one path, it will not be overridden by SD on the other path (first come, first served behavior), to avoid protection switching that cannot improve signal quality.
o 1つのパスのSDによって切り替えが完了すると、信号品質を改善できない保護切り替えを回避するために、もう1つのパスのSDによってオーバーライドされません（先着順の動作）。
The SD message indicates that the transmitting node has identified degradation of the signal or integrity of the packet received on either the working path or the protection path. The FPath field SHALL identify the path that is reporting the degraded condition (i.e., if the protection path, then FPath is set to 0; if the working path, then FPath is set to 1), and the Path field SHALL indicate where the data traffic is being transported (i.e., if the working path is selected, then Path is set to 0; if the protection path is selected, then Path is set to 1).
SDメッセージは、送信ノードが信号の劣化または現用パスまたは保護パスのいずれかで受信したパケットの整合性を識別したことを示します。 FPathフィールドは、劣化状態を報告しているパスを識別しなければならず（つまり、保護パスの場合、FPathは0に設定されます。現用パスの場合、FPathは1に設定されます）、Pathフィールドはデータの場所を示す必要があります（SHALL）トラフィックが転送されています（つまり、現用パスが選択されている場合、パスは0に設定されます。保護パスが選択されている場合、パスは1に設定されます）。
When the SD condition is cleared and the protected domain is recovering from the situation, the Wait-to-Restore (WTR) timer SHALL be used if the protected domain is configured for revertive behavior. The WTR timer SHALL be started at the node that recovers from a local degraded condition on the working path.
SD状態がクリアされ、保護されたドメインが状況から回復しているときに、保護されたドメインが復元動作用に構成されている場合は、復元待ち（WTR）タイマーを使用する必要があります。 WTRタイマーは、現用パスのローカルの劣化状態から回復するノードで開始する必要があります（SHALL）。
Protection switching against SD is always provided by a selector bridge duplicating user data traffic and feeding it to both the working path and the protection path under SD condition. When a local or remote SD occurs on either the working path or the protection path, the node SHALL duplicate user data traffic and SHALL feed it to both the working path and the protection path. The packet duplication SHALL continue as long as any SD condition exists in the protected domain. When the SD condition is cleared, in revertive operation, the packet duplication SHALL continue in the WTR state and SHALL stop when the node leaves the WTR state; while in non-revertive operation, the packet duplication SHALL stop immediately.
SDに対する保護切り替えは、ユーザーデータトラフィックを複製し、SD状態で現用パスと保護パスの両方に供給するセレクタブリッジによって常に提供されます。ローカルまたはリモートSDが現用パスまたは予備パスのいずれかで発生すると、ノードはユーザーデータトラフィックを複製し、現用パスと予備パスの両方にフィードする必要があります（SHALL）。パケットの複製は、保護されたドメインにSD状態が存在する限り継続する必要があります。 SD状態がクリアされると、リバーティブ操作では、パケットの複製はWTR状態で継続し、ノードがWTR状態を離れると停止する必要があります。非リバーティブ操作では、パケットの複製はすぐに停止する必要があります。
The selector bridge with the packet duplication under SD condition, which is a non-permanent bridge, is considered to be a 1:1 protection architecture.
SD状態でパケットが重複するセレクタブリッジは、非永続的なブリッジであり、1：1保護アーキテクチャと見なされます。
Protection switching against SD does not introduce any modification to the operation of the selector at the sink node described in [RFC6378]. The selector chooses either the working or protection path from which to receive the normal traffic in both 1:1 and 1+1 architectures. The position of the selector, i.e., which path to receive the traffic, is determined by the PSC protocol in bidirectional switching or by the local input in unidirectional switching.
SDに対する保護切り替えは、[RFC6378]で説明されているシンクノードでのセレクターの動作に変更を導入しません。セレクタは、1：1と1 + 1の両方のアーキテクチャで通常のトラフィックを受信するための現用パスまたは保護パスを選択します。セレクタの位置、つまりトラフィックを受信するパスは、双方向スイッチングのPSCプロトコルまたは単方向スイッチングのローカル入力によって決定されます。
In order to support the MS behavior described in Section 6.3 and the protection against SD described in Section 7.3, it is necessary to expand rules for treating equal-priority inputs.
セクション6.3で説明されているMSの動作とセクション7.3で説明されているSDに対する保護をサポートするには、同じ優先度の入力を処理するためのルールを拡張する必要があります。
For equal-priority local inputs, such as MS and SD, apply a simple first-come, first-served rule. Once a local input is determined as the highest priority local input, then a subsequent equal-priority local input requesting a different action, i.e., the action results in the same PSC Request field but different FPath value, will not be presented to the PSC Control Logic as the highest local request. Furthermore, in the case of an MS command, the subsequent local MS command requesting a different action will be cancelled.
MSやSDなどの優先順位が等しいローカル入力の場合は、単純な先着順のルールを適用します。ローカル入力が最も優先度の高いローカル入力として決定されると、別のアクションを要求する後続の同じ優先度のローカル入力、つまり同じアクションが同じPSCリクエストフィールドになりますが、FPath値が異なるため、PSCコントロールに提示されません最も高いローカルリクエストとしてのロジック。さらに、MSコマンドの場合、別のアクションを要求する後続のローカルMSコマンドはキャンセルされます。
If a node is in a remote state due to a remote SD (or MS) message, a subsequent local input having the same priority but requesting a different action to the PSC Control Logic will be considered as having lower priority than the remote message and will be ignored. For example, if a node is in remote Switching Administrative state due to a remote MS-P, then any subsequent local MS-W SHALL be ignored and automatically cancelled. If a node is in remote Unavailable state due to a remote SD-P, then any subsequent local SD-W input will be ignored. However, the local SD-W SHALL continue to appear in the Local Request Logic as long as the SD condition exists, but it SHALL NOT be the top-priority global request, which determines the state transition at the PSC Control Logic.
リモートSD（またはMS）メッセージが原因でノードがリモート状態にある場合、同じ優先度を持つが、PSC制御ロジックに異なるアクションを要求する後続のローカル入力は、リモートメッセージよりも低い優先度を持つと見なされ、無視されます。たとえば、リモートMS-Pが原因でノードがリモートスイッチング管理状態にある場合、後続のローカルMS-Wはすべて無視され、自動的にキャンセルされる必要があります。リモートSD-Pが原因でノードがリモート使用不可状態にある場合、後続のローカルSD-W入力は無視されます。ただし、ローカルSD-Wは、SD条件が存在する限り、ローカルリクエストロジックに表示され続ける必要がありますが、PSC制御ロジックでの状態遷移を決定する最優先のグローバルリクエストであってはなりません。
Cases where two end-points of the protected domain simultaneously receive local triggers of the same priority that request different actions may occur (for example, one node receives SD-P and the other receives SD-W). Subsequently, each node will receive a remote message with the opposing action indication. To address these cases, we define the following priority resolution rules:
保護されたドメインの2つのエンドポイントが、異なるアクションを要求する同じ優先度のローカルトリガーを同時に受信する場合があります（たとえば、一方のノードがSD-Pを受信し、もう一方のノードがSD-Wを受信する）。その後、各ノードは、反対のアクションを示すリモートメッセージを受信します。これらのケースに対処するために、次の優先順位解決ルールを定義します。
o When MS-W and MS-P occur simultaneously at both nodes, MS-W SHALL be considered as having higher priority than MS-P at both nodes.
o MS-WとMS-Pが両方のノードで同時に発生する場合、MS-Wは両方のノードでMS-Pよりも優先度が高いと見なされるものとします（SHALL）。
o When SD-W and SD-P occur simultaneously at both nodes, the SD on the standby path (the path from which the selector does not select the user data traffic) is considered as having higher priority than the SD on the active path (the path from which the selector selects the user data traffic) regardless of its origin (local or remote message). Therefore, no unnecessary protection switching is performed, and the user data traffic continues to be selected from the active path.
o SD-WとSD-Pが両方のノードで同時に発生する場合、スタンバイパスのSD（セレクターがユーザーデータトラフィックを選択しないパス）は、アクティブパスのSDより優先度が高いと見なされます（セレクタがユーザーデータトラフィックを選択するパス）。したがって、不必要な保護切り替えは行われず、ユーザーデータトラフィックは引き続きアクティブパスから選択されます。
In the preceding paragraphs, "simultaneously" refers to the case a sent SD (or MS) request has not been confirmed by the remote end in bidirectional protection switching. When a local node that has transmitted an SD message receives an SD (or MS) message that indicates a different value of Path field from the value of Path field in the transmitted SD (or MS) message, both the local and remote SD requests are considered to occur simultaneously.
前の段落で「同時に」とは、送信されたSD（またはMS）要求が、双方向保護切り替えでリモートエンドによって確認されなかった場合を指します。 SDメッセージを送信したローカルノードが、送信されたSD（またはMS）メッセージのパスフィールドの値とは異なるパスフィールドの値を示すSD（またはMS）メッセージを受信すると、ローカルとリモートの両方のSD要求が同時に発生すると見なされます。
The addition of support for protection against SD requires modification to the PSC Control Logic (including the state machine) relative to that described in [RFC6378]. Sections 10 and 11 present the PSC Control Logic when all capabilities of APS mode are enabled.
SDに対する保護のサポートを追加するには、[RFC6378]で説明されているものと比較して、PSC制御ロジック（ステートマシンを含む）を変更する必要があります。セクション10と11は、APSモードのすべての機能が有効な場合のPSC制御ロジックを示しています。
The EXER command is used to verify the correct operation of the PSC communication, such as the aliveness of the Local Request Logic, the integrity of the PSC Control Logic, the PSC message generation and reception mechanism, and the integrity of the protection path. EXER does not trigger any actual traffic switching.
EXERコマンドは、ローカル要求ロジックの活性、PSC制御ロジックの整合性、PSCメッセージの生成と受信のメカニズム、保護パスの整合性など、PSC通信の正しい動作を確認するために使用されます。 EXERは実際のトラフィック切り替えをトリガーしません。
The command is only relevant for bidirectional protection switching, since it is dependent upon receiving a response from the remote node. The EXER command is assigned lower priority than any switching message. It may be used regardless of the traffic usage of the working path.
このコマンドは、リモートノードからの応答の受信に依存しているため、双方向保護切り替えにのみ関連します。 EXERコマンドには、どのスイッチングメッセージよりも低い優先順位が割り当てられます。現用パスのトラフィック使用状況に関係なく使用できます。
When a node receives a remote EXER message, it SHOULD respond with a Reverse Request (RR) message with the FPath and Path fields set according to the current condition of the node. The RR message SHALL be generated only in response to a remote EXER message.
ノードがリモートEXERメッセージを受信すると、ノードの現在の状態に従って設定されたFPathフィールドとPathフィールドを含む逆要求（RR）メッセージで応答する必要があります（SHOULD）。 RRメッセージは、リモートEXERメッセージへの応答としてのみ生成される必要があります。
This command is documented in R84 of [RFC5654].
このコマンドは、[RFC5654]のR84で文書化されています。
If EXER commands are input at both ends, then a race condition may arise. This is resolved as follows:
EXERコマンドが両端で入力されると、競合状態が発生する可能性があります。これは次のように解決されます。
o If a node has issued EXER and receives EXER before receiving RR, it MUST treat the received EXER as it would an RR, and it SHOULD NOT respond with RR.
o ノードがEXERを発行し、RRを受信する前にEXERを受信した場合、受信したEXERをRRと同様に処理する必要があり、RRで応答してはなりません（SHOULD NOT）。
The following PSC Requests are added to the PSC Request field to support the Exercise command (see also Section 14.1):
次のPSCリクエストがPSCリクエストフィールドに追加され、エクササイズコマンドをサポートします（セクション14.1も参照）。
(3) Exercise - indicates that the transmitting end-point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR, or DNR message whose transmission is stopped by EXER.
（3）演習-送信エンドポイントが保護チャネルとメカニズムを行使していることを示します。 FPathとPathは、EXERによって送信が停止されたNo Request（NR）、RR、またはDNRメッセージと同じ値に設定されます。
(2) Reverse Request - indicates that the transmitting end-point is responding to an EXER command from the remote node. FPath and Path are set to the same value of the NR or DNR message whose transmission is stopped by RR.
（2）リバースリクエスト-送信エンドポイントがリモートノードからのEXERコマンドに応答していることを示します。 FPathとPathは、RRによって送信が停止されたNRまたはDNRメッセージと同じ値に設定されます。
The relative priorities of EXER and RR are defined in Section 10.2.
EXERとRRの相対的な優先順位は、セクション10.2で定義されています。
A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. The format of the Capabilities TLV is:
機能は、[RFC6378]の図2に示すPSCメッセージ内のオプションのTLVフィールドに配置される機能TLVで使用が通知される個々の動作です。機能TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Capabilities | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of Capabilities TLV
図1：機能TLVのフォーマット
The value of the Type field is 1.
Typeフィールドの値は1です。
The value of the Length field is the length of the Flags field in octets. The length of the Flags field MUST be a multiple of 4 octets and MUST be the minimum required to signal all the required capabilities.
長さフィールドの値は、オクテット単位のフラグフィールドの長さです。 Flagsフィールドの長さは4オクテットの倍数である必要があり、すべての必要な機能を通知するために必要な最小値である必要があります。
Section 4 to Section 8 discuss five capabilities that are signaled using the five most significant bits; if a node wishes to signal these five capabilities, it MUST send a Flags field of 4 octets. A node would send a Flags field greater than 4 octets only if it had more than 32 Capabilities to indicate. All unused bits MUST be set to zero.
セクション4からセクション8では、上位5ビットを使用して通知される5つの機能について説明します。ノードがこれらの5つの機能を通知したい場合は、4オクテットのフラグフィールドを送信する必要があります。ノードは、32を超える機能を示す場合にのみ、4オクテットを超えるFlagsフィールドを送信します。未使用のビットはすべてゼロに設定する必要があります。
If the bit assigned for an individual capability is set to 1, it indicates the sending node's intent to use that capability in the protected domain. If a bit is set to 0, the sending node does not intend to use the indicated capability in the protected domain. Note that it is not possible to distinguish between the intent not to use a capability and a node's complete non-support (i.e., lack of implementation) of a given capability.
個々の機能に割り当てられたビットが1に設定されている場合、保護されたドメインでその機能を使用する送信ノードの意図を示します。ビットが0に設定されている場合、送信ノードは、保護されたドメインで指定された機能を使用する意図はありません。機能を使用しない意図とノードの完全な非サポート（つまり、実装の欠如）で特定の機能を区別できないことに注意してください。
This document defines five specific capabilities that are described in Section 4 to Section 8. Each capability is assigned bit as follows:
このドキュメントでは、セクション4からセクション8で説明する5つの特定の機能を定義しています。各機能には、次のようにビットが割り当てられています。
0x80000000: priority modification
0x80000000：優先度の変更
0x40000000: non-revertive behavior modification
0x40000000：非リバーティブな動作の変更
0x20000000: support of MS-W command
0x20000000：MS-Wコマンドのサポート
0x10000000: support of protection against SD
0x10000000：SDに対する保護のサポート
0x08000000: support of EXER command
0x08000000：EXERコマンドのサポート
If all the five capabilities should be used, a node SHALL set the Flags field to 0xF8000000.
5つの機能すべてを使用する必要がある場合、ノードはフラグフィールドを0xF8000000に設定する必要があります（SHALL）。
A node MUST include its Capabilities TLV in every PSC message that it transmits. The transmission and acceptance of the PSC message is described in Section 4.1 of [RFC6378].
ノードは、送信するすべてのPSCメッセージにその機能TLVを含める必要があります。 PSCメッセージの送信と受け入れについては、[RFC6378]のセクション4.1で説明されています。
When a node receives a Capabilities TLV, it MUST compare the Flags value to its most recent Flags value transmitted by the node. If the two are equal, the protected domain is said to be running in the mode indicated by that set of capabilities (see Section 9.2). If the sent and received Capabilities TLVs are not equal, this indicates a Capabilities TLV mismatch. When this happens, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves the mismatch between the two end-points.
ノードが機能TLVを受信すると、フラグ値をノードによって送信された最新のフラグ値と比較する必要があります。 2つが等しい場合、保護されたドメインは、その機能セットによって示されるモードで実行されていると見なされます（セクション9.2を参照）。送信および受信された機能TLVが等しくない場合、これは機能TLVの不一致を示しています。これが発生した場合、ノードはオペレーターに警告しなければならず（MUST）、オペレーターが2つのエンドポイント間の不一致を解決するまで、保護切り替えを実行してはなりません（MUST NOT）。
A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes -- PSC and APS. Capabilities TLVs with other combinations than the one specified by a mode are not supported in this specification.
モードは、与えられた一連の機能です。モードは省略形です。個々の値またはモードの名前で一連の機能を参照しても、プロトコルの動作は変わりません。このドキュメントでは、PSCとAPSの2つのモードを定義しています。モードで指定されたもの以外の組み合わせの機能TLVは、この仕様ではサポートされていません。
PSC mode is defined as the lack of support for any of the additional capabilities defined in this document -- that is, a Capabilities set of 0x0. It is the behavior specified in [RFC6378].
PSCモードは、このドキュメントで定義されている追加機能（つまり、0x0の機能セット）がサポートされていないことと定義されています。 [RFC6378]で指定されている動作です。
There are two ways to declare PSC mode. A node can send no Capabilities TLV at all since there are no TLV units defined in [RFC6378], or it can send a Capabilities TLV with Flags value set to 0x0. In order to allow backward compatibility between two end-points -- one which supports sending the Capabilities TLV, and one which does not, the node that has the ability to send and process the PSC mode Capabilities TLV MUST be able to both send the PSC mode Capabilities TLV and send no Capabilities TLV at all. An implementation MUST be configurable between these two options.
PSCモードを宣言するには2つの方法があります。 [RFC6378]で定義されたTLVユニットがないため、ノードは機能TLVをまったく送信できません。または、フラグ値が0x0に設定された機能TLVを送信できます。 2つのエンドポイント間の下位互換性を可能にするために、1つは機能TLVの送信をサポートし、もう1つはサポートしない、PSCモードを送信および処理する機能を持つノードは、両方のPSCを送信できる必要がありますモード機能TLVを送信し、機能TLVをまったく送信しません。実装は、これらの2つのオプション間で構成可能でなければなりません。
APS mode is defined as the use of all the five specific capabilities, which are described in Sections 4 to 8 in this document. APS mode is indicated with the Flags value of 0xF8000000.
APSモードは、このドキュメントのセクション4から8で説明されている5つの特定の機能すべての使用として定義されています。 APSモードは、フラグ値0xF8000000で示されます。
This section and the following section define the behavior of the PSC protocol when all of the aforementioned capabilities are enabled, i.e., APS mode.
このセクションと次のセクションでは、前述の機能がすべて有効になっているとき（つまり、APSモード）のPSCプロトコルの動作を定義します。
This document defines two new values for the "Request" field in the PSC protocol message that is shown in Figure 2 of [RFC6378] as follows:
このドキュメントは、[RFC6378]の図2に示されているPSCプロトコルメッセージの "Request"フィールドの2つの新しい値を次のように定義します。
(2) Reverse Request
（2）リバースリクエスト
(3) Exercise
（3）エクササイズ
See also Section 14.1 of this document.
このドキュメントのセクション14.1も参照してください。
Based on the description in Sections 3 and 4.3.2 in [RFC6378], the priorities of multiple outstanding local inputs are evaluated in the Local Request Logic, where the highest priority local input (highest local request) is determined. This highest local request is passed to the PSC Control Logic that will determine the higher-priority input (top-priority global request) between the highest local request and the last received remote message. When a remote message comes to the PSC Control Logic, the top-priority global request is determined between this remote message and the highest local request that is present. The top-priority global request is used to determine the state transition, which is described in Section 11. In this document, in order to simplify the description on the PSC Control Logic, we strictly decouple the priority evaluation from the state transition table lookup.
[RFC6378]のセクション3と4.3.2の説明に基づいて、複数の未処理のローカル入力の優先度がローカルリクエストロジックで評価され、最高の優先度のローカル入力（最高のローカルリクエスト）が決定されます。この最高のローカルリクエストは、最高のローカルリクエストと最後に受信したリモートメッセージ間の優先度の高い入力（最優先グローバルリクエスト）を決定するPSC制御ロジックに渡されます。リモートメッセージがPSC制御ロジックに到達すると、このリモートメッセージと存在する最も高いローカル要求の間で最優先のグローバル要求が決定されます。最優先のグローバル要求を使用して、状態遷移を決定します。これについては、セクション11で説明します。このドキュメントでは、PSC制御ロジックの説明を簡略化するために、優先順位の評価を状態遷移表のルックアップから厳密に切り離しています。
The priorities for both local and remote requests are defined as follows from highest to lowest:
ローカル要求とリモート要求の両方の優先順位は、最高から最低まで次のように定義されています。
o Operator Clear (Local only)
o オペレータークリア（ローカルのみ）
o Lockout of protection (Local and Remote)
o 保護のロックアウト（ローカルおよびリモート）
o Clear Signal Fail or Degrade (Local only)
o Clear Signal Fail or Degrade（Local only）
o Signal Fail on Protection path (Local and Remote)
o 保護パスの信号障害（ローカルおよびリモート）
o Forced Switch (Local and Remote) o Signal Fail on Working path (Local and Remote)
o強制切り替え（ローカルおよびリモート）o現用パスの信号障害（ローカルおよびリモート）
o Signal Degrade on either Protection path or Working path (Local and Remote)
o 保護パスまたは現用パス（ローカルおよびリモート）での信号劣化
o Manual Switch to either Protection path or Working path (Local and Remote)
o 保護パスまたは現用パス（ローカルおよびリモート）への手動切り替え
o WTR Timer Expiry (Local only)
o WTRタイマーの有効期限（ローカルのみ）
o WTR (Remote only)
o WTR（リモートのみ）
o Exercise (Local and Remote)
o 演習（ローカルおよびリモート）
o Reverse Request (Remote only)
o リバースリクエスト（リモートのみ）
o Do-Not-Revert (Remote only)
o 元に戻さない（リモートのみ）
o No Request (Remote and Local)
o 要求なし（リモートおよびローカル）
Note that the "Local only" requests are not transmitted to the remote node. Likewise, the "Remote only" requests do not exist in the Local Request Logic as local inputs. For example, the priority of WTR only applies to the received WTR message, which is generated from the remote node. The remote node that is running the WTR timer in the WTR state has no local request.
「ローカルのみ」の要求はリモートノードに送信されないことに注意してください。同様に、「リモートのみ」のリクエストは、ローカル入力ロジックとしてローカルリクエストロジックに存在しません。たとえば、WTRの優先度は、リモートノードから生成された受信WTRメッセージにのみ適用されます。 WTR状態でWTRタイマーを実行しているリモートノードにはローカル要求がありません。
The remote SF and SD on either the working path or the protection path and the remote MS to either the working path or the protection path are indicated by the values of the Request and FPath fields in the PSC message.
現用パスまたは保護パス上のリモートSFおよびSD、および現用パスまたは保護パスへのリモートMSは、PSCメッセージのRequestフィールドとFPathフィールドの値によって示されます。
The remote request from the remote node is assigned a priority just below the same local request except for NR and equal-priority requests, such as SD and MS. Since a received NR message needs to be used in the state transition table lookup when there is no outstanding local request, the remote NR request SHALL have a higher priority than the local NR. For the equal-priority requests, see Section 10.2.1.
リモートノードからのリモートリクエストには、NRとSDやMSなどの同じ優先度のリクエストを除いて、同じローカルリクエストのすぐ下に優先度が割り当てられます。未処理のローカル要求がない場合は、受信したNRメッセージを状態遷移テーブルのルックアップで使用する必要があるため、リモートNR要求はローカルNRより高い優先度を持つ必要があります。優先度が等しいリクエストについては、10.2.1項を参照してください。
As stated in Section 10.2, the remote request from the remote node is assigned a priority just below the same local request. However, for equal-priority requests, such as SD and MS, the priority SHALL be evaluated as described in this section.
セクション10.2で述べたように、リモートノードからのリモート要求には、同じローカル要求のすぐ下に優先順位が割り当てられます。ただし、SDやMSなどの優先度が等しいリクエストの場合、このセクションで説明するように優先度を評価する必要があります。
For equal-priority local requests, the first-come, first-served rule SHALL be applied. Once a local request appears in the Local Request Logic, a subsequent equal-priority local request requesting a different action, i.e., the action results in the same Request value but a different FPath value, SHALL be considered to have a lower priority. Furthermore, in the case of an MS command, the subsequent local MS command requesting a different action SHALL be rejected and cleared.
優先度が等しいローカルリクエストの場合、先着順のルールが適用されます。ローカルリクエストロジックにローカルリクエストが表示されると、後続の同じ優先度のローカルリクエストが別のアクションをリクエストします。つまり、アクションは同じリクエスト値になりますが、FPath値は異なりますが、優先度は低いと見なされます。さらに、MSコマンドの場合、別のアクションを要求する後続のローカルMSコマンドは拒否されてクリアされる必要があります。
When the priority is evaluated in the PSC Control Logic between the highest local request and a remote request, the following equal-priority resolution rules SHALL be applied:
優先度がPSC制御ロジックで最も高いローカル要求とリモート要求の間で評価されるとき、次の優先度の等しい解決ルールが適用されます。
o If two requests request the same action, i.e., the same Request and FPath values, then the local request SHALL be considered to have a higher priority than the remote request.
o 2つのリクエストが同じアクション、つまり同じリクエストとFPath値をリクエストする場合、ローカルリクエストはリモートリクエストよりも優先度が高いと見なされます。
o When the highest local request comes to the PSC Control Logic, if the remote request that requests a different action exists, then the highest local request SHALL be ignored and the remote request SHALL remain to be the top-priority global request. In the case of an MS command, the local MS command requesting a different action SHALL be cancelled.
o 最も高いローカル要求がPSC制御ロジックに到達したときに、別のアクションを要求するリモート要求が存在する場合、最も高いローカル要求は無視され、リモート要求は最優先のグローバル要求のままである必要があります（SHALL）。 MSコマンドの場合、別のアクションを要求するローカルMSコマンドをキャンセルする必要があります。
o When the remote request comes to the PSC Control Logic, if the highest local request that requests a different action exists, then the top-priority global request SHALL be determined by the following rules:
o リモートリクエストがPSC制御ロジックに到達したときに、別のアクションをリクエストする最も高いローカルリクエストが存在する場合、最優先のグローバルリクエストが次のルールによって決定される必要があります。
* For MS requests, the MS-W request SHALL be considered to have a higher priority than the MS-P request. The node that has the local MS-W request SHALL maintain the local MS-W request as the top-priority global request. The other node that has the local MS-P request SHALL cancel the MS-P command and SHALL generate "Operator Clear" internally as the top-priority global request.
* MSリクエストの場合、MS-WリクエストはMS-Pリクエストよりも優先度が高いと見なされるものとします（SHALL）。ローカルMS-W要求を持つノードは、ローカルMS-W要求を最優先グローバル要求として維持する必要があります。ローカルMS-P要求を持つ他のノードは、MS-Pコマンドをキャンセルし（SHALL）、最優先のグローバル要求として内部的に「Operator Clear」を生成する必要があります（SHALL）。
* For SD requests, the SD on the standby path (the path from which the selector does not select the user data traffic) SHALL be considered to have a higher priority than the SD on the active path (the path from which the selector selects the user data traffic) regardless of its origin (local or remote message). The node that has the SD on the standby path SHALL maintain the local SD on the standby path request as the top-priority global request. The other node that has local SD on the active path SHALL use the remote SD on the standby path as the top-priority global request to lookup the state transition table. The differentiation of the active and standby paths is based upon which path had been selected for the user data traffic when each node detected its local SD.
* SD要求の場合、スタンバイパス（セレクタがユーザーデータトラフィックを選択しないパス）のSDは、アクティブパス（セレクタが選択するパス）のSDよりも優先度が高いと見なす必要があります（SHALL）。ユーザーデータトラフィック）の発生元（ローカルまたはリモートメッセージ）に関係なく。スタンバイパスにSDがあるノードは、スタンバイパスリクエストのローカルSDを最優先グローバルリクエストとして維持する必要があります。アクティブパスにローカルSDを持つ他のノードは、状態遷移表を検索する最優先グローバル要求として、スタンバイパス上のリモートSDを使用する必要があります（SHALL）。アクティブパスとスタンバイパスの区別は、各ノードがローカルSDを検出したときにユーザーデータトラフィック用に選択されたパスに基づいています。
A local input indicating a defect, such as SF-P, SF-W, SD-P, and SD-W, SHALL be accepted and retained persistently in the Local Request Logic as long as the defect condition exists. If there is any higher-priority local input than the local defect input, the higher-priority local input is passed to the PSC Control Logic as the highest local request, but the local defect input cannot be removed but remains in the Local Request Logic. When the higher-priority local input is cleared, the local defect will become the highest local request if the defect condition still exists.
SF-P、SF-W、SD-P、SD-Wなどの欠陥を示すローカル入力は、欠陥条件が存在する限り、ローカル要求ロジックで受け入れられ、永続的に保持される必要があります。ローカル欠陥入力よりも優先度の高いローカル入力がある場合、優先度の高いローカル入力は最高のローカル要求としてPSC制御ロジックに渡されますが、ローカル欠陥入力は削除できず、ローカル要求ロジックに残ります。優先順位の高いローカル入力がクリアされると、障害状態がまだ存在する場合、ローカル障害は最も高いローカル要求になります。
The Operator Clear (OC) command, SFDc, and WTR Timer Expiry are not persistent. Once they appear to the Local Request Logic and complete all the operations in the protection-switching control, they SHALL disappear.
オペレータークリア（OC）コマンド、SFDc、およびWTRタイマーの有効期限は永続的ではありません。それらがローカルリクエストロジックに表示され、保護切り替え制御のすべての操作を完了すると、それらは消えます。
The LO, FS, MS, and EXER commands SHALL be rejected if there is any higher-priority local input in the Local Request Logic. If a new higher-priority local request (including an operator command) is accepted, any previous lower-priority local operator command SHALL be cancelled. When any higher-priority remote request is received, a lower-priority local operator command SHALL be cancelled. The cancelled operator command is cleared. If the operators wish to renew the cancelled command, then they should reissue the command.
ローカル要求ロジックに優先度の高いローカル入力がある場合、LO、FS、MS、およびEXERコマンドは拒否されます。優先順位の高い新しいローカルリクエスト（オペレーターコマンドを含む）が受け入れられると、以前の優先順位の低いローカルオペレーターコマンドはキャンセルされます。優先度の高いリモート要求を受信すると、優先度の低いローカルオペレーターコマンドをキャンセルする必要があります。キャンセルされたオペレーターコマンドはクリアされます。オペレーターが取り消されたコマンドを更新したい場合は、コマンドを再発行する必要があります。
When there is a change in the highest local request or in remote PSC messages, the top-priority global request SHALL be evaluated, and the state transition tables SHALL be looked up in the PSC Control Logic. The following rules are applied to the operation related to the state transition table lookup.
最上位のローカル要求またはリモートPSCメッセージに変更がある場合、最優先のグローバル要求が評価され、PSC制御ロジックで状態遷移表が検索される必要があります（SHALL）。状態遷移表の検索に関連する操作には、以下のルールが適用されます。
o If the top-priority global request, which determines the state transition, is the highest local request, the local state transition table in Section 11.1 SHALL be used to decide the next state of the node. Otherwise, the remote state transition table in Section 11.2 SHALL be used.
o 状態遷移を決定する最優先のグローバル要求が最も高いローカル要求である場合、セクション11.1のローカル状態遷移表を使用して、ノードの次の状態を決定する必要があります（SHALL）。それ以外の場合は、セクション11.2のリモート状態遷移表を使用する必要があります（SHALL）。
o If in remote state, the highest local defect condition (SF-P, SF-W, SD-P, or SD-W) SHALL always be reflected in the Request and FPath fields.
o リモート状態の場合、最も高いローカル障害状態（SF-P、SF-W、SD-P、またはSD-W）が常に要求フィールドとFPathフィールドに反映されます。
o For the node currently in the local state, if the top-priority global request is changed to OC or SFDc, causing the next state to be Normal, WTR, or DNR, then all the local and remote requests SHALL be re-evaluated as if the node is in the state specified in the footnotes to the state transition tables, before deciding the final state. If there are no active requests, the node enters the state specified in the footnotes to the state transition tables. This re-evaluation is an internal operation confined within the local node, and the PSC messages are generated according to the final state.
o 現在ローカル状態にあるノードの場合、最優先のグローバル要求がOCまたはSFDcに変更され、次の状態が通常、WTR、またはDNRになると、すべてのローカルおよびリモート要求は、あたかも再評価される必要があります（SHALL）。ノードは、最終的な状態を決定する前に、状態遷移表の脚注で指定された状態にあります。アクティブな要求がない場合、ノードは状態遷移表の脚注で指定された状態に入ります。この再評価はローカルノード内に限定された内部操作であり、PSCメッセージは最終状態に従って生成されます。
o The WTR timer is started only when the node that has recovered from a local failure or degradation enters the WTR state. A node that is entering into the WTR state due to a remote WTR message does not start the WTR timer. The WTR timer SHALL be stopped when any local or remote request triggers the state change out of the WTR state.
o WTRタイマーは、ローカルの障害または劣化から回復したノードがWTR状態になったときにのみ開始されます。リモートWTRメッセージが原因でWTR状態に入っているノードは、WTRタイマーを開始しません。 WTRタイマーは、ローカルまたはリモートの要求がWTR状態から状態変更をトリガーしたときに停止する必要があります（SHALL）。
The extended states, as they appear in the table, are as follows:
表に表示されている拡張状態は次のとおりです。
N Normal state
UA:LO:L Unavailable state due to local LO command
UA:P:L Unavailable state due to local SF-P
UA:DP:L Unavailable state due to local SD-P
UA:LO:R Unavailable state due to remote LO message
UA:P:R Unavailable state due to remote SF-P message
UA:DP:R Unavailable state due to remote SD-P message
PF:W:L Protecting Failure state due to local SF-W
PF:DW:L Protecting Failure state due to local SD-W
PF:W:R Protecting Failure state due to remote SF-W message
PF:DW:R Protecting Failure state due to remote SD-W message
SA:F:L Switching Administrative state due to local FS command
SA:MW:L Switching Administrative state due to local MS-W command
SA:MP:L Switching Administrative state due to local MS-P command
SA:F:R Switching Administrative state due to remote FS message
SA:MW:R Switching Administrative state due to remote MS-W message
SA:MP:R Switching Administrative state due to remote MS-P message
WTR Wait-to-Restore state
DNR Do-not-Revert state
E::L Exercise state due to local EXER command
E::R Exercise state due to remote EXER message
Each state corresponds to the transmission of a particular set of Request, FPath, and Path fields. The table below lists the message that is generally sent in each particular state. If the message to be sent in a particular state deviates from the table below, it is noted in the footnotes of the state transition tables.
各状態は、Request、FPath、およびPathフィールドの特定のセットの送信に対応しています。以下の表は、一般的に特定の各状態で送信されるメッセージの一覧です。特定の状態で送信されるメッセージが以下の表から逸脱している場合は、状態遷移表の脚注に示されています。
State Request(FPath,Path)
------- ------------------------------------
N NR(0,0)
UA:LO:L LO(0,0)
UA:P:L SF(0,0)
UA:DP:L SD(0,0)
UA:LO:R highest local request(local FPath,0)
UA:P:R highest local request(local FPath,0)
UA:DP:R highest local request(local FPath,0)
PF:W:L SF(1,1)
PF:DW:L SD(1,1)
PF:W:R highest local request(local FPath,1)
PF:DW:R highest local request(local FPath,1)
SA:F:L FS(1,1)
SA:MW:L MS(0,0)
SA:MP:L MS(1,1)
SA:F:R highest local request(local FPath,1)
SA:MW:R NR(0,0)
SA:MP:R NR(0,1)
WTR WTR(0,1)
DNR DNR(0,1)
E::L EXER(0,x), where x is the existing Path value
when Exercise command is issued.
E::R RR(0,x), where x is the existing Path value
when RR message is generated.
Some operation examples of APS mode are shown in Appendix D.
APSモードの操作例のいくつかを付録Dに示します。
In the state transition tables below, the letter 'i' stands for "ignore" and is an indication to remain in the current state and continue transmitting the current PSC message
以下の状態遷移表では、文字「i」は「無視」を表し、現在の状態のままで現在のPSCメッセージを送信し続けることを示しています
| OC | LO | SFDc | SF-P | FS | SF-W |
--------+-----+---------+------+--------+--------+--------+
N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
UA:LO:L | (1) | i | i | i | i | i |
UA:P:L | i | UA:LO:L | (1) | i | i | i |
UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L |
UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i |
PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L |
PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i |
SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
WTR | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
E::L | (5) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
(Continued)
（続く）
| SD-P | SD-W | MS-W | MS-P | WTRExp | EXER
--------+---------+---------+---------+---------+--------+------
N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
UA:LO:L | i | i | i | i | i | i
UA:P:L | i | i | i | i | i | i
UA:DP:L | i | i | i | i | i | i
UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i
UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i
UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i
PF:W:L | i | i | i | i | i | i
PF:DW:L | i | i | i | i | i | i
PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i
PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i
SA:F:L | i | i | i | i | i | i
SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i
SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i
SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i
SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i
SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i
WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i
DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i
E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
NOTES:
ノート：
(1) Re-evaluate to determine the final state as if the node is in the Normal state. If there are no active requests, the node enters the Normal State.
（1）ノードが通常の状態であるかのように、最終的な状態を決定するために再評価します。アクティブな要求がない場合、ノードは通常の状態になります。
(2) In the case that both local input after SFDc and the last received remote message are NR, the node enters into the WTR state when the domain is configured for revertive behavior, or the node enters into the DNR state when the domain is configured for non-revertive behavior. In all the other cases, where one or more active requests exist, re-evaluate to determine the final state as if the node is in the Normal state.
（2）SFDc後のローカル入力と最後に受信したリモートメッセージの両方がNRである場合、ドメインがリバーティブ動作用に構成されているとノードはWTR状態になり、ドメインが構成されているとノードはDNR状態になります非リバーティブ動作の場合。他のすべてのケースでは、1つ以上のアクティブな要求が存在する場合、ノードを通常の状態であるかのように再評価して最終状態を決定します。
(3) Re-evaluate to determine final state as if the node is in the Normal state when the domain is configured for revertive behavior, or as if the node is in the DNR state when the domain is configured for non-revertive behavior. If there are no active requests, the node enters either the Normal state when the domain is configured for revertive behavior or the DNR state when the domain is configured for non-revertive behavior.
（3）ドメインがリバーティブ動作用に構成されている場合はノードが通常状態であるか、またはドメインが非リバーティブ動作用に構成されている場合はノードがDNR状態であるかのように、最終状態を決定するために再評価します。アクティブな要求がない場合、ドメインが復元動作用に構成されている場合、ノードは通常状態になるか、ドメインが非復元動作用に構成されている場合、DNR状態になります。
(4) Remain in the WTR state and send an NR(0,1) message. Stop the WTR timer if it is running. In APS mode, OC can cancel the WTR timer and hasten the state transition to the Normal state as in other transport networks.
（4）WTR状態のままで、NR（0,1）メッセージを送信します。実行中の場合は、WTRタイマーを停止します。 APSモードでは、OCはWTRタイマーをキャンセルし、他のトランスポートネットワークと同様に、通常状態への状態遷移を早めることができます。
(5) If Path value is 0, re-evaluate to determine final state as if the node is in the Normal state. If Path value is 1, re-evaluate to determine final state as if the node is in the DNR state. If there are no active requests, the node enters the Normal state when Path value is 0, or the DNR state when Path value is 1.
（5）Path値が0の場合、ノードを通常の状態であるかのように再評価して最終状態を決定します。パス値が1の場合、ノードがDNR状態にあるかのように再評価して最終状態を決定します。アクティブな要求がない場合、ノードは、パス値が0の場合は通常状態になり、パス値が1の場合はDNR状態になります。
(6) Remain in the WTR state and send an NR(0,1) message.
（6）WTR状態のままで、NR（0,1）メッセージを送信します。
| LO | SF-P | FS | SF-W | SD-P | SD-W |
--------+---------+--------+--------+--------+---------+---------+
N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:LO:L | i | i | i | i | i | i |
UA:P:L | UA:LO:R | i | i | i | i | i |
UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) |
UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R |
PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i |
PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (8) | i |
PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R |
PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | i |
SA:F:L | UA:LO:R | UA:P:R | i | i | i | i |
SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R |
SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
(Continued)
（続く）
| MS-W | MS-P | WTR | EXER | RR | DNR | NR
--------+---------+---------+-----+------+----+------+----
N | SA:MW:R | SA:MP:R | i | E::R | i | i | i
UA:LO:L | i | i | i | i | i | i | i
UA:P:L | i | i | i | i | i | i | i
UA:DP:L | i | i | i | i | i | i | i
UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
PF:W:L | i | i | i | i | i | i | i
PF:DW:L | i | i | i | i | i | i | i
PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
SA:F:L | i | i | i | i | i | i | i
SA:MW:L | i | i | i | i | i | i | i
SA:MP:L | i | i | i | i | i | i | i
SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N
SA:MW:R | i | SA:MP:R | i | E::R | i | i | N
SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N
WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12)
DNR | SA:MW:R | SA:MP:R | (13)| E::R | i | i | i
E::L | SA:MW:R | SA:MP:R | i | i | i | i | i
E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N
NOTES:
ノート：
(7) If the received SD-W message has Path=0, ignore the message. If the received SD-W message has Path=1, go to the PF:DW:R state and transmit an SD(0,1) message.
（7）受信したSD-Wメッセージのパスが0の場合、メッセージは無視してください。受信したSD-Wメッセージのパスが1の場合、PF：DW：R状態に移行し、SD（0,1）メッセージを送信します。
(8) If the received SD-P message has Path=1, ignore the message. If the received SD-P message has Path=0, go to the UA:DP:R state and transmit an SD(1,0) message.
（8）受信したSD-Pメッセージのパスが1の場合、メッセージは無視してください。受信したSD-Pメッセージのパスが0の場合、UA：DP：R状態に移行し、SD（1,0）メッセージを送信します。
(9) Transition to the WTR state and continue to send the current message.
（9）WTR状態に移行し、現在のメッセージを送信し続けます。
(10) Transition to the DNR state and continue to send the current message.
（10）DNR状態に移行し、現在のメッセージを送信し続けます。
(11) If the received NR message has Path=1, transition to the WTR state if the domain is configured for revertive behavior, else transition to the DNR state. If the received NR message has Path=0, transition to the Normal state.
（11）受信したNRメッセージにPath = 1がある場合、ドメインがリバーティブ動作用に構成されている場合はWTR状態に遷移し、そうでない場合はDNR状態に遷移します。受信したNRメッセージのパスが0の場合、通常状態に移行します。
(12) If the receiving node's WTR timer is running, maintain the current state and message. If the WTR timer is not running, transition to the Normal state.
（12）受信ノードのWTRタイマーが実行中の場合は、現在の状態とメッセージを維持します。 WTRタイマーが実行されていない場合は、通常状態に移行します。
(13) Transit to the WTR state and send an NR(0,1) message. The WTR timer is not initiated.
（13）WTR状態に遷移し、NR（0,1）メッセージを送信します。 WTRタイマーは開始されません。
The state transition tables given in Sections 11.1 and 11.2 are for bidirectional protection switching, where remote PSC protocol messages are used to determine the protection-switching actions. 1+1 unidirectional protection switching does not require the remote information in the PSC protocol message and acts upon local inputs only. The state transition by local inputs in Section 11.1 SHALL be reused for 1+1 unidirectional protection under the following conditions:
セクション11.1および11.2に示す状態遷移表は、双方向の保護切り替え用であり、リモートPSCプロトコルメッセージを使用して保護切り替えアクションを決定します。 1 + 1単方向保護スイッチングは、PSCプロトコルメッセージのリモート情報を必要とせず、ローカル入力にのみ作用します。セクション11.1のローカル入力による状態遷移は、次の条件下で1 + 1単方向保護に再利用する必要があります。
o The value of Request field in the received remote message is ignored and always assumed to be no request.
o 受信したリモートメッセージのRequestフィールドの値は無視され、常に要求がないと見なされます。
o Replace footnote (4) with "Stop the WTR timer and transit to the Normal state."
o 脚注（4）を「WTRタイマーを停止し、通常の状態に移行する」に置き換えます。
o Replace footnote (6) with "Transit to the Normal state."
o 脚注（6）を「通常状態への移行」に置き換えます。
o Exercise command is not relevant.
o 運動コマンドは関係ありません。
The remote PSC message that is received from the remote node is subject to the detection of provisioning mismatch and protocol failure conditions. In APS mode, provisioning mismatches are handled as follows:
リモートノードから受信したリモートPSCメッセージは、プロビジョニングの不一致とプロトコル障害の状態の検出の影響を受けます。 APSモードでは、プロビジョニングの不一致は次のように処理されます。
o If the PSC message is received from the working path due to working/protection path configuration mismatch, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves this path configuration mismatch.
o 現用パスと保護パスの設定の不一致が原因でPSCメッセージが現用パスから受信された場合、ノードはオペレーターに警告し、オペレーターがこのパス設定の不一致を解決するまで保護切り替えを実行してはなりません。
o In the case that the mismatch happens in the two-bit "Protection Type (PT)" field, which indicates permanent/selector bridge type and uni/bidirectional switching type:
o 2ビットの「保護タイプ（PT）」フィールドで不一致が発生した場合、これは永続的/セレクターブリッジタイプと単方向/双方向スイッチングタイプを示します。
* If the value of the PT field of one side is 2 (i.e., selector bridge) and that of the other side is 1 or 3 (i.e., permanent bridge), then this event MUST be notified to the operator and each node MUST NOT perform any protection switching until the operator resolves this bridge type mismatch.
* 一方のPTフィールドの値が2（つまり、セレクターブリッジ）であり、もう一方の側の値が1または3（つまり、永続的なブリッジ）である場合、このイベントはオペレーターに通知する必要があり、各ノードは実行してはなりません（MUST NOT）オペレータがこのブリッジタイプの不一致を解決するまでの保護切り替え。
* If the bridge type matches but the switching type mismatches, i.e., one side has PT=1 (unidirectional switching) while the other side has PT=2 or 3 (bidirectional switching), then the node provisioned for bidirectional switching SHOULD fall back to unidirectional switching to allow interworking. The node SHOULD notify the operator of this event.
* ブリッジタイプは一致するが、スイッチングタイプが一致しない場合、つまり、一方の側にPT = 1（単方向スイッチング）があり、もう一方の側にPT = 2または3（双方向スイッチング）がある場合、双方向スイッチング用にプロビジョニングされたノードは単方向にフォールバックする必要があります（SHOULD）。インターワーキングを許可するための切り替え。ノードはこのイベントをオペレーターに通知する必要があります（SHOULD）。
o If the "Revertive (R)" bit mismatches, two sides will interwork and traffic is protected according to the state transition definition given in Section 11. The node SHOULD notify the operator of this event.
o 「Revertive（R）」ビットが一致しない場合、セクション11で指定された状態遷移の定義に従って、2つのサイドが相互作用し、トラフィックが保護されます。ノードは、このイベントをオペレーターに通知する必要があります（SHOULD）。
o If the Capabilities TLV mismatches, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves the mismatch in the Capabilities TLV.
o 機能TLVが一致しない場合、ノードはオペレーターに警告しなければならず、オペレーターが機能TLVの不一致を解決するまで、保護切り替えを実行してはなりません（MUST NOT）。
The following are the protocol failure situations and the actions to be taken:
以下は、プロトコル障害の状況と実行するアクションです。
o No match in sent "Data Path (Path)" and received "Data Path (Path)" for more than 50 ms: The node MAY continue to perform protection switching and SHOULD notify the operator of this event.
o 送信された「データパス（パス）」と受信された「データパス（パス）」が50ミリ秒を超えて一致しない：ノードは引き続き保護切り替えを実行でき、このイベントをオペレーターに通知する必要があります（SHOULD）。
o No PSC message is received on the protection path during at least 3.5 times the long PSC message interval (e.g., at least 17.5 seconds with a default message interval of 5 seconds), and there is no defect on the protection path: The node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves this defect.
o 長いPSCメッセージ間隔の少なくとも3.5倍（たとえば、デフォルトのメッセージ間隔5秒で少なくとも17.5秒）の間、保護パスでPSCメッセージが受信されず、保護パスに欠陥がない場合：ノードはアラートを送信する必要がありますオペレーターは、オペレーターがこの欠陥を解決するまで、保護切り替えを実行してはなりません。
This document introduces no new security risks. [RFC6378] points out that MPLS relies on assumptions about the difficulty of traffic injection and assumes that the control plane does not have end-to-end security. [RFC5920] describes MPLS security issues and generic methods for securing traffic privacy and integrity. MPLS use should conform to such advice.
このドキュメントでは、新しいセキュリティリスクは紹介されていません。 [RFC6378]は、MPLSがトラフィックインジェクションの困難さに関する仮定に依存し、コントロールプレーンにエンドツーエンドのセキュリティがないと仮定していることを指摘しています。 [RFC5920]は、MPLSのセキュリティ問題と、トラフィックのプライバシーと整合性を保護するための一般的な方法について説明しています。 MPLSの使用は、このようなアドバイスに従う必要があります。
In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA maintains the "MPLS PSC Request Registry".
「Generic Associated Channel（G-ACh）Parameters」レジストリで、IANAは「MPLS PSC Request Registry」を維持しています。
IANA has assigned the following two new code points from this registry.
IANAは、このレジストリから次の2つの新しいコードポイントを割り当てました。
Value Description Reference
----- --------------------- ---------------
2 Reverse Request (this document)
3 Exercise (this document)
In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA maintains the "MPLS PSC TLV Registry".
「Generic Associated Channel（G-ACh）Parameters」レジストリで、IANAは「MPLS PSC TLVレジストリ」を維持します。
This document defines the following new value for the Capabilities TLV type in the "MPLS PSC TLV Registry".
このドキュメントでは、「MPLS PSC TLVレジストリ」の機能TLVタイプに次の新しい値を定義しています。
Value Description Reference
------ --------------------- ---------------
1 Capabilities (this document)
IANA has created and now maintains a new registry within the "Generic Associated Channel (G-ACh) Parameters" registry called "MPLS PSC Capability Flag Registry". All flags within this registry SHALL be allocated according to the "Standards Action" procedures as specified in RFC 5226 [RFC5226].
IANAは、「MPLS PSC機能フラグレジストリ」と呼ばれる「Generic Associated Channel（G-ACh）Parameters」レジストリ内に新しいレジストリを作成し、現在維持しています。このレジストリ内のすべてのフラグは、RFC 5226 [RFC5226]で指定されている「標準アクション」手順に従って割り当てられる必要があります（SHALL）。
The length of each flag MUST be a multiple of 4 octets. This document defines 4-octet flags. Flags greater than 4 octets SHALL be used only if more than 32 Capabilities need to be defined. The flags defined in this document are:
各フラグの長さは4オクテットの倍数でなければなりません。このドキュメントでは、4オクテットフラグを定義しています。 4オクテットを超えるフラグは、32を超える機能を定義する必要がある場合にのみ使用してください。このドキュメントで定義されているフラグは次のとおりです。
Bit Hex Value Capability Reference
---- ---------- ----------------------------------- ---------------
0 0x80000000 priority modification (this document)
1 0x40000000 non-revertive behavior modification (this document)
2 0x20000000 support of MS-W command (this document)
3 0x10000000 support of protection against SD (this document)
4 0x08000000 support of EXER command (this document)
5-31 Unassigned (this document)
The authors would like to thank Yaacov Weingarten, Yuji Tochio, Malcolm Betts, Ross Callon, Qin Wu, and Xian Zhang for their valuable comments and suggestions on this document.
このドキュメントに関する貴重なコメントと提案を提供してくれたYaacov Weingarten、Yuji Tochio、Malcolm Betts、Ross Callon、Qin Wu、Xian Zhangに感謝します。
We would also like to acknowledge explicit text provided by Loa Andersson and Adrian Farrel.
また、ロアアンダーソン氏とエイドリアンファレル氏が提供した露骨な文章も認めたいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「要件、MPLSトランスポートプロファイル」、RFC 5654、2009年9月。
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC6378] Weingarten、Y.、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、2011年10月。
[G8031] International Telecommunication Union, "Ethernet Linear Protection Switching", ITU-T Recommendation G.8031/Y.1342, June 2011.
[G8031]国際電気通信連合、「イーサネット線形保護スイッチング」、ITU-T勧告G.8031 / Y.1342、2011年6月。
[G841] International Telecommunication Union, "Types and characteristics of SDH network protection architectures", ITU-T Recommendation G.841, October 1998.
[G841]国際電気通信連合、「SDHネットワーク保護アーキテクチャのタイプと特性」、ITU-T勧告G.841、1998年10月。
[G873.1] International Telecommunication Union, "Optical Transport Network (OTN): Linear protection", ITU-T Recommendation G.873.1, July 2011.
[G873.1]国際電気通信連合、「光伝送ネットワーク（OTN）：線形保護」、ITU-T勧告G.873.1、2011年7月。
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）のリカバリ（保護および復元）用語」、RFC 4427、2006年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372] Sprecher、N。およびA. Farrel、「MPLS Transport Profile（MPLS-TP）Survivability Framework」、RFC 6372、2011年9月。
The sequence diagram shown is an example of the out-of-service scenarios based on the priority level defined in [RFC6378]. The first PSC message that differs from the previous PSC message is shown.
示されているシーケンス図は、[RFC6378]で定義されている優先度レベルに基づくサービス停止シナリオの例です。前のPSCメッセージとは異なる最初のPSCメッセージが表示されます。
A Z
| |
(1) |-- NR(0,0) ------>| (1)
|<----- NR(0,0) ---|
| |
| |
| (FS issued at Z) | (2)
(3) |<------ FS(1,1) --|
|-- NR(0,1) ------>|
| |
| |
(4) | (SF on P(A<-Z)) |
| |
| |
| (Clear FS at Z) | (5)
(6) | X <- NR(0,0) --|
| |
| |
(1) Each end is in the Normal state and transmits NR(0,0) messages.
（1）両端が正常状態にあり、NR（0,0）メッセージを送信します。
(2) When a FS command is issued at node Z, node Z goes into local Protecting Administrative state (PA:F:L) and begins transmission of an FS(1,1) message.
（2）ノードZでFSコマンドが発行されると、ノードZはローカルの保護管理状態（PA：F：L）になり、FS（1,1）メッセージの送信を開始します。
(3) A remote FS message causes node A to go into remote Protecting Administrative state (PA:F:R), and node A begins transmitting NR(0,1) messages.
（3）リモートFSメッセージにより、ノードAはリモート保護管理状態（PA：F：R）になり、ノードAはNR（0,1）メッセージの送信を開始します。
(4) When node A detects a unidirectional SF-P, node A keeps sending an NR(0,1) message because SF-P is ignored under the PA:F:R state.
（4）ノードAが単方向SF-Pを検出すると、PA：F：R状態ではSF-Pが無視されるため、ノードAはNR（0,1）メッセージを送信し続けます。
(5) When a Clear command is issued at node Z, node Z goes into the Normal state and begins transmission of NR(0,0) messages.
（5）ノードZでClearコマンドが発行されると、ノードZは通常状態になり、NR（0,0）メッセージの送信を開始します。
(6) But, node A cannot receive PSC message because of local unidirectional SF-P. Because no valid PSC message is received over a period of several successive message intervals, the last valid received message remains applicable, and the node A continue to transmit an NR(0,1) message in the PA:F:R state.
（6）しかし、ローカル単方向SF-Pのため、ノードAはPSCメッセージを受信できません。いくつかの連続するメッセージ間隔の期間にわたって有効なPSCメッセージが受信されないため、最後の有効な受信メッセージは引き続き適用され、ノードAはPA：F：R状態でNR（0,1）メッセージを送信し続けます。
Now, there exists a mismatch between the selector and bridge positions of node A (transmitting an NR(0,1) message) and node Z (transmitting an NR(0,0) message). It results in an out-of-service situation even when there is neither SF-W nor FS.
ここで、ノードA（NR（0,1）メッセージを送信）とノードZ（NR（0,0）メッセージを送信）のセレクターとブリッジの位置の間に不一致が存在します。 SF-WもFSもない場合でも、サービスが停止します。
Appendix B. An Example of a Sequence Diagram Showing the Problem with the Priority Level of SFc
付録B. SFcの優先度レベルの問題を示すシーケンス図の例
An example of a sequence diagram showing the problem with the priority level of SFc defined in [RFC6378] is given below. The following sequence diagram depicts the case when the bidirectional signal fails. However, other cases with unidirectional signal fails can result in the same problem. The first PSC message that differs from the previous PSC message is shown.
[RFC6378]で定義されているSFcの優先度の問題を示すシーケンス図の例を以下に示します。次のシーケンス図は、双方向信号が失敗した場合を示しています。ただし、単方向信号が失敗する他のケースでも同じ問題が発生する可能性があります。前のPSCメッセージとは異なる最初のPSCメッセージが表示されます。
A Z
| |
(1) |-- NR(0,0) ------>| (1)
|<----- NR(0,0) ---|
| |
| |
(2) | (SF on P(A<->Z)) | (2)
|-- SF(0,0) ------>|
|<------ SF(0,0) --|
| |
| |
(3) | (SF on W(A<->Z)) | (3)
| |
| |
(4) | (Clear SF-P) | (4)
| |
| |
(5) | (Clear SF-W) | (5)
| |
| |
(1) Each end is in the Normal state and transmits NR(0,0) messages.
（1）両端が正常状態にあり、NR（0,0）メッセージを送信します。
(2) When SF-P occurs, each node enters into the UA:P:L state and transmits SF(0,0) messages. Traffic remains on the working path.
（2）SF-Pが発生すると、各ノードはUA：P：L状態に入り、SF（0,0）メッセージを送信します。トラフィックは現用パス上に残ります。
(3) When SF-W occurs, each node remains in the UA:P:L state as SF-W has a lower priority than SF-P. Traffic is still on the working path. Traffic cannot be delivered, as both the working path and the protection path are experiencing signal fails.
（3）SF-Wが発生すると、SF-WはSF-Pよりも優先順位が低いため、各ノードはUA：P：L状態のままになります。トラフィックはまだ現用パス上にあります。現用パスと保護パスの両方で信号障害が発生しているため、トラフィックを配信できません。
(4) When SF-P is cleared, the local "Clear SF-P" request cannot be presented to the PSC Control Logic, which takes the highest local request and runs the PSC state machine, since the priority of "Clear SF-P" is lower than that of SF-W. Consequently, there is no change in state, and the selector and/or bridge keep pointing at the working path, which has SF condition.
（4）SF-Pがクリアされると、ローカルの "Clear SF-P"要求をPSC制御ロジックに提示できません。PSC制御ロジックは、最も高いローカル要求を受け取り、PSCステートマシンを実行します。 「SF-Wより低いです。その結果、状態に変化はなく、セレクターやブリッジはSF状態の現用パスを指さし続けます。
Now, traffic cannot be delivered while the protection path is recovered and available. It should be noted that the same problem will occur in the case that the sequence of SF-P and SF-W events is changed.
現在、保護パスが復旧して使用可能になっている間は、トラフィックを配信できません。なお、SF-PイベントとSF-Wイベントのシーケンスを変更した場合も同様の問題が発生します。
If we further continue with this sequence to see what will happen after SF-W is cleared:
SF-Wがクリアされた後に何が起こるかを確認するためにこのシーケンスをさらに続ける場合：
(5) When SF-W is cleared, the local "Clear SF-W" request can be passed to the PSC Control Logic, as there is no higher-priority local input, but it will be ignored in the PSC Control Logic according to the state transition definition in [RFC6378]. There will be no change in state or protocol message transmitted.
（5）SF-Wがクリアされると、優先度の高いローカル入力がないため、ローカルの「Clear SF-W」リクエストをPSC制御ロジックに渡すことができますが、PSC制御ロジックでは無視されます。 [RFC6378]の状態遷移定義。送信される状態またはプロトコルメッセージに変更はありません。
As SF-W is now cleared and the selector and/or bridge are still pointing at the working path, traffic delivery is resumed. However, each node is in the UA:P:L state and transmitting SF(0,0) messages, while there exists no outstanding request for protection switching. Moreover, any future legitimate protection-switching requests, such as SF-W, will be rejected as each node thinks the protection path is unavailable.
SF-Wがクリアされ、セレクタまたはブリッジ、あるいはその両方がまだ現用パスを指しているため、トラフィックの配信が再開されます。ただし、各ノードはUA：P：L状態にあり、SF（0,0）メッセージを送信していますが、保護切り替えの未処理の要求はありません。さらに、SF-Wなどの将来の正当な保護切り替え要求は、各ノードが保護パスを利用できないと判断するため拒否されます。
The "Freeze" command applies only to the local node of the protection group and is not signaled to the remote node. This command freezes the state of the protection group. Until the Freeze is cleared, additional local commands are rejected, and condition changes and received PSC information are ignored.
「フリーズ」コマンドは、保護グループのローカルノードにのみ適用され、リモートノードには通知されません。このコマンドは、保護グループの状態を凍結します。フリーズが解除されるまで、追加のローカルコマンドは拒否され、状態の変化と受信したPSC情報は無視されます。
The "Clear Freeze" command clears the local freeze. When the Freeze command is cleared, the state of the protection group is recomputed based on the persistent condition of the local triggers.
「Clear Freeze」コマンドは、ローカルフリーズをクリアします。 Freezeコマンドがクリアされると、ローカルトリガーの永続的な状態に基づいて保護グループの状態が再計算されます。
Because the freeze is local, if the freeze is issued at one end only, a failure of protocol can occur as the other end is open to accept any operator command or a fault condition.
フリーズはローカルであるため、フリーズが一方の端でのみ発行された場合、他方の端が開いてオペレーターコマンドまたは障害状態を受け入れるため、プロトコルの障害が発生する可能性があります。
The sequence diagrams shown in this section are only a few examples of the APS mode operations. The first PSC protocol message that differs from the previous message is shown. The operation of the hold-off timer is omitted. The Request, FPath, and Path fields whose values are changed during PSC message exchange are shown. For an example, SF(1,0) represents a PSC message with the following field values: Request=SF, FPath=1, and Path=0. The values of the other fields remain unchanged from the initial configuration. W(A->Z) and P(A->Z) indicate the working path and the protection path in the direction of A to Z, respectively.
このセクションに示されているシーケンス図は、APSモード操作のほんの数例にすぎません。前のメッセージとは異なる最初のPSCプロトコルメッセージが表示されます。ホールドオフタイマーの動作は省略しています。 PSCメッセージ交換中に値が変更されるRequest、FPath、およびPathフィールドが表示されます。例として、SF（1,0）は、Request = SF、FPath = 1、およびPath = 0のフィールド値を持つPSCメッセージを表します。他のフィールドの値は、初期構成から変更されていません。 W（A-> Z）とP（A-> Z）は、それぞれAからZ方向の現用パスと予備パスを示します。
Example 1. 1:1 bidirectional protection switching (revertive operation) - Unidirectional SF case
例1. 1：1双方向保護スイッチング（リバーティブ動作）-単方向SFケース
A Z
| |
(1) |<---- NR(0,0)---->| (1)
| |
| |
(2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3)
(4) |<----- NR(0,1)----|
| |
| |
(5) | (Clear SF-W) |
|---- WTR(0,1)---->|
/| |
| | |
WTR timer | |
| | |
\| |
(6) |---- NR(0,1)----->| (7)
(8) |<----- NR(0,0)----|
|---- NR(0,0)----->| (9)
| |
(1) The protected domain is operating without any defect, and the working path is used for delivering the traffic in the Normal state.
（1）保護ドメインは問題なく動作しており、正常な状態でトラフィックを配信するために現用パスが使用されています。
(2) SF-W occurs in the Z to A direction. Node A enters into the PF:W:L state and generates an SF(1,1) message. Both the selector and bridge of node A are pointing at the protection path.
（2）SF-Wは、ZからA方向に発生します。ノードAはPF：W：L状態に入り、SF（1,1）メッセージを生成します。ノードAのセレクターとブリッジの両方が保護パスを指しています。
(3) Upon receiving an SF(1,1) message, node Z sets both the selector and bridge to the protection path. As there is no local request in node Z, node Z generates an NR(0,1) message in the PF:W:R state.
（3）SF（1,1）メッセージを受信すると、ノードZはセレクターとブリッジの両方を保護パスに設定します。ノードZにはローカル要求がないため、ノードZはPF：W：R状態でNR（0,1）メッセージを生成します。
(4) Node A confirms that the remote node is also selecting the protection path.
（4）ノードAは、リモートノードも保護パスを選択していることを確認します。
(5) Node A detects clearing of SF condition, starts the WTR timer, and sends a WTR(0,1) message in the WTR state.
（5）ノードAはSF状態のクリアを検出し、WTRタイマーを開始し、WTR状態でWTR（0,1）メッセージを送信します。
(6) Upon expiration of the WTR timer, node A sets both the selector and bridge to the working path and sends an NR(0,1) message.
（6）WTRタイマーの満了時に、ノードAはセレクターとブリッジの両方を現用パスに設定し、NR（0,1）メッセージを送信します。
(7) Node Z is notified that the remote request has been cleared. Node Z transits to the Normal state and sends an NR(0,0) message.
（7）リモート要求がクリアされたことがノードZに通知されます。ノードZは通常状態に遷移し、NR（0,0）メッセージを送信します。
(8) Upon receiving an NR(0,0) message, node A transits to the Normal state and sends an NR(0,0) message.
（8）ノードAはNR（0,0）メッセージを受信すると、通常状態に遷移し、NR（0,0）メッセージを送信します。
(9) It is confirmed that the remote node is also selecting the working path.
（9）リモートノードも現用パスを選択していることを確認します。
Example 2. 1:1 bidirectional protection switching (revertive operation) - Bidirectional SF case - Inconsistent WTR timers
例2. 1：1双方向保護スイッチング（リバーティブ操作）-双方向SFケース-一貫性のないWTRタイマー
A Z
| |
(1) |<---- NR(0,0)---->| (1)
| |
| |
(2) | (SF on W(A<->Z)) | (2)
|<---- SF(1,1)---->|
| |
| |
(3) | (Clear SF-W) | (3)
|<---- NR(0,1)---->|
(4) |<--- WTR(0,1) --->| (4)
/| |\
| | | |
WTR timer | | WTR timer
| | | |
| | |/
| |<------ NR(0,1)---| (5)
| | |
\| |
(6) |--- NR(0,1)------>|
|<------ NR(0,0)---| (7)
(8) |--- NR(0,0)------>|
| |
(1) Each end is in the Normal state and transmits NR(0,0) messages.
（1）両端が正常状態にあり、NR（0,0）メッセージを送信します。
(2) When SF-W occurs, each node enters into the PF:W:L state and transmits SF(1,1) messages. Traffic is switched to the protection path. Upon receiving an SF(1,1) message, each node confirms that the remote node is also sending and receiving the traffic from the protection path.
（2）SF-Wが発生すると、各ノードはPF：W：L状態に入り、SF（1,1）メッセージを送信します。トラフィックは保護パスに切り替えられます。 SF（1,1）メッセージを受信すると、各ノードは、リモートノードも保護パスからトラフィックを送受信していることを確認します。
(3) When SF-W is cleared, each node transits to the PF:W:R state and transmits NR(0,1) messages as the last received message is SF-W.
（3）SF-Wがクリアされると、最後に受信したメッセージがSF-Wであるため、各ノードはPF：W：R状態に遷移し、NR（0,1）メッセージを送信します。
(4) Upon receiving NR(0,1) messages, each node goes into the WTR state, starts the WTR timer, and sends the WTR(0,1) messages.
（4）NR（0,1）メッセージを受信すると、各ノードはWTR状態に入り、WTRタイマーを開始し、WTR（0,1）メッセージを送信します。
(5) Upon expiration of the WTR timer in node Z, node Z sends an NR(0,1) message as the last received APS message was WTR. When the NR(0,1) message arrives at node A, node A maintains the WTR state and keeps sending current WTR messages as described in the state transition table.
（5）最後に受信したAPSメッセージがWTRだったので、ノードZのWTRタイマーが満了すると、ノードZはNR（0,1）メッセージを送信します。 NR（0,1）メッセージがノードAに到着すると、ノードAはWTR状態を維持し、状態遷移表で説明されているように現在のWTRメッセージを送信し続けます。
(6) Upon expiration of the WTR timer in node A, node A sends an NR(0,1) message.
（6）ノードAのWTRタイマーが満了すると、ノードAはNR（0,1）メッセージを送信します。
(7) When the NR(0,1) message arrives at node Z, node Z moves to the Normal state, sets both the selector and bridge to the working path, and sends an NR(0,0) message.
（7）NR（0,1）メッセージがノードZに到着すると、ノードZは通常状態に移行し、セレクターとブリッジの両方を現用パスに設定し、NR（0,0）メッセージを送信します。
(8) The received NR(0,0) message causes node A to go to the Normal state. Now, the traffic is switched back to the working path.
（8）NR（0,0）メッセージを受信すると、ノードAは通常状態になります。これで、トラフィックは現用パスに切り替えられます。
Example 3. 1:1 bidirectional protection switching - R bit mismatch
例3. 1：1双方向保護スイッチング-Rビットの不一致
This example shows that both sides will interwork and the traffic is protected when one side (node A) is configured as revertive operation and the other (node Z) is configured as non-revertive operation. The interworking is covered in the state transition tables.
この例は、一方の側（ノードA）がリバーティブ操作として構成され、もう一方の側（ノードZ）が非リバーティブ操作として構成されている場合、両側が相互作用し、トラフィックが保護されることを示しています。インターワーキングについては、状態遷移表で説明しています。
(revertive) A Z (non-revertive)
| |
(1) |<---- NR(0,0)---->| (1)
| |
| |
(2) | (SF on W(A<->Z)) | (2)
|<---- SF(1,1)---->|
| |
| |
(3) | (Clear SF-W) | (3)
|<---- NR(0,1)---->|
(4) |<----- DNR(0,1)---| (4)
/|-- WTR(0,1)------>|
| |<----- NR(0,1)----| (5)
| | |
WTR timer | |
| | |
| | |
\| |
(6) |--- NR(0,1)------>|
|<------ NR(0,0)---| (7)
(8) |--- NR(0,0)------>|
| |
(1) Each end is in the Normal state and transmits NR(0,0) messages.
（1）両端が正常状態にあり、NR（0,0）メッセージを送信します。
(2) When SF-W occurs, each node enters into the PF:W:L state and transmits SF(l,l) messages. Traffic is switched to the protection path. Upon receiving an SF(1,1) message, each node confirms that the remote node is also sending and receiving the traffic on the protection path.
（2）SF-Wが発生すると、各ノードはPF：W：L状態に入り、SF（l、l）メッセージを送信します。トラフィックは保護パスに切り替えられます。 SF（1,1）メッセージを受信すると、各ノードは、リモートノードも保護パスでトラフィックを送受信していることを確認します。
(3) When SF-W is cleared, each node transits to the PF:W:R state and transmits NR(0,1) messages as the last received message is SF-W.
（3）SF-Wがクリアされると、最後に受信したメッセージがSF-Wであるため、各ノードはPF：W：R状態に遷移し、NR（0,1）メッセージを送信します。
(4) Upon receiving NR(0,1) messages, node A goes into the WTR state, starts the WTR timer, and sends WTR(0,1) messages. At the same time, node Z transits to the DNR state and sends a DNR(0,1) message.
（4）NR（0,1）メッセージを受信すると、ノードAはWTR状態に入り、WTRタイマーを開始し、WTR（0,1）メッセージを送信します。同時に、ノードZはDNR状態に遷移し、DNR（0,1）メッセージを送信します。
(5) When the WTR message arrives at node Z, node Z transits to the WTR state and sends an NR(0,1) message according to the state transition table. At the same time, the DNR message arrived at node Z is ignored according to the state transition table. Therefore, node Z, which is configured as non-revertive operation, is operating as if in revertive operation.
（5）WTRメッセージがノードZに到着すると、ノードZはWTR状態に遷移し、状態遷移表に従ってNR（0,1）メッセージを送信します。同時に、ノードZに到着したDNRメッセージは、状態遷移表に従って無視されます。したがって、非リバーティブ動作として構成されているノードZは、リバーティブ動作であるかのように動作しています。
(6) Upon expiration of the WTR timer in node A, node A sends an NR(0,1) message.
（6）ノードAのWTRタイマーが満了すると、ノードAはNR（0,1）メッセージを送信します。
(7) When the NR(0,1) message arrives at node Z, node Z moves to the Normal state, sets both the selector and bridge to the working path, and sends an NR(0,0) message.
（7）NR（0,1）メッセージがノードZに到着すると、ノードZは通常状態に移行し、セレクターとブリッジの両方を現用パスに設定し、NR（0,0）メッセージを送信します。
(8) The received NR(0,0) message causes node A to transit to the Normal state. Now, the traffic is switched back to the working path.
（8）受信したNR（0,0）メッセージにより、ノードAは通常状態に遷移します。これで、トラフィックは現用パスに切り替えられます。
Authors' Addresses
著者のアドレス
Jeong-dong Ryoo (editor) ETRI 218 Gajeongno Yuseong-gu, Daejeon 305-700 South Korea Phone: +82-42-860-5384 EMail: ryoo@etri.re.kr
Jeong-dong Ryoo（editor）ETRI 218 Gajeongno Yuseong-gu、Daejeon 305-700 South Korea電話：+ 82-42-860-5384メール：ryoo@etri.re.kr
Eric Gray (editor) Ericsson EMail: eric.gray@ericsson.com
エリック・グレイ（編集者）エリクソンEメール：eric.gray@ericsson.com
Huub van Helvoort Huawei Technologies Karspeldreef 4, Amsterdam 1101 CJ The Netherlands Phone: +31 20 4300936 EMail: huub.van.helvoort@huawei.com
Huub van Helvoort Huawei Technologies Karspeldreef 4、アムステルダム1101 CJオランダ電話：+31 20 4300936 Eメール：huub.van.helvoort@huawei.com
Alessandro D'Alessandro Telecom Italia via Reiss Romoli, 274 Torino 10148 Italy Phone: +39 011 2285887 EMail: alessandro.dalessandro@telecomitalia.it
Alessandro D'Alessandro Telecom Italia via Reiss Romoli、274 Turin 10148 Italy電話：+39 011 2285887メール：alessandro.dalessandro@telecomitalia.it
Taesik Cheung ETRI 218 Gajeongno Yuseong-gu, Daejeon 305-700 South Korea Phone: +82-42-860-5646 EMail: cts@etri.re.kr
Taesik Cheung ETRI 218 -305-700大田市大田市儒城区218電話：+ 82-42-860-5646メール：cts@etri.re.kr
Eric Osborne EMail: eric.osborne@notcom.com
エリックオズボーンEメール：eric.osborne@notcom.com