[要約] RFC 6378は、MPLS-TP線形保護に関する標準化されたプロトコル仕様です。その目的は、MPLSネットワークでの信頼性と回復性を向上させるために、線形保護メカニズムを提供することです。
Internet Engineering Task Force (IETF) Y. Weingarten, Ed.
Request for Comments: 6378 Nokia Siemens Networks
Category: Standards Track S. Bryant
ISSN: 2070-1721 E. Osborne
Cisco
N. Sprecher
Nokia Siemens Networks
A. Fulignoli, Ed.
Ericsson
October 2011
MPLS Transport Profile (MPLS-TP) Linear Protection
MPLS輸送プロファイル（MPLS-TP）線形保護
Abstract
概要
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
このドキュメントは、IETF MPLSおよびPSEUDOWIREエミュレーションエッジツーエッジ（PWE3）アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されているパケット輸送ネットワークの機能と機能をサポートする。
This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document.
このドキュメントは、MPLS-TP Survivability Frameworkドキュメント（RFC 6372）で説明されている機能に対応し、そのドキュメントで説明されているように、線形保護の保護状態調整の機能を満たすために使用できるプロトコルを定義します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6378.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6378で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Protection Architectures ...................................4
1.2. Scope of the Document ......................................5
2. Conventions Used in This Document ...............................6
2.1. Acronyms ...................................................6
2.2. Definitions and Terminology ................................7
3. Protection State Control Logic ..................................7
3.1. Local Request Logic ........................................9
3.2. Remote Requests ...........................................11
3.3. PSC Control Logic .........................................12
3.4. PSC Message Generator .....................................12
3.5. Wait-to-Restore (WTR) Timer ...............................12
3.6. PSC Control States ........................................13
3.6.1. Local and Remote State .............................14
4. Protection State Coordination (PSC) Protocol ...................14
4.1. Transmission and Acceptance of PSC Control Packets ........15
4.2. Protocol Format ...........................................16
4.2.1. PSC Ver Field ......................................16
4.2.2. PSC Request Field ..................................17
4.2.3. Protection Type (PT) Field .........................18
4.2.4. Revertive (R) Field ................................18
4.2.5. Fault Path (FPath) Field ...........................19
4.2.6. Data Path (Path) Field .............................19
4.2.7. Additional TLV Information .........................19
4.3. Principles of Operation ...................................20
4.3.1. Basic Operation ....................................20
4.3.2. Priority of Inputs .................................21
4.3.3. Operation of PSC States ............................22
5. IANA Considerations ............................................33
5.1. Pseudowire Associated Channel Type ........................33
5.2. PSC Request Field .........................................33
5.3. Additional TLVs ...........................................34
6. Security Considerations ........................................34
7. Acknowledgements ...............................................35
8. Contributing Authors ...........................................36
9. References .....................................................37
9.1. Normative References ......................................37
9.2. Informative References ....................................37
Appendix A. PSC State Machine Tables ..............................39
Appendix B. Exercising the Protection Domain ......................44
The MPLS Transport Profile (MPLS-TP) [RFC5921] is a framework for the construction and operation of packet-switched transport networks based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of [RFC5654].
MPLSトランスポートプロファイル（MPLS-TP）[RFC5921]は、MPLS（[RFC3031]および[RFC3032]）およびPseudowires（PWS）のアーキテクチャに基づくパケットスイッチされた輸送ネットワークの構築と動作のフレームワークです（[RFC39855）]および[RFC5659]）および[RFC5654]の要件。
Network survivability is the ability of a network to recover traffic delivery following failure, or degradation, of network resources. The MPLS-TP Survivability Framework [RFC6372] is a framework for survivability in MPLS-TP networks, and describes recovery elements, types, methods, and topological considerations, focusing on mechanisms for recovering MPLS-TP Label Switched Paths (LSPs).
ネットワークの生存性とは、ネットワークリソースの障害または劣化後のトラフィック配信を回復するネットワークの能力です。MPLS-TP Survivability Framework [RFC6372]は、MPLS-TPネットワークの生存可能性のフレームワークであり、MPLS-TPラベルスイッチ付きパス（LSP）の回復メカニズムに焦点を当てた回復要素、種類、方法、およびトポロジカルな考慮事項を説明しています。
Linear protection in mesh networks -- networks with arbitrary interconnectivity between nodes -- is described in Section 4.7 of [RFC6372]. Linear protection provides rapid and simple protection switching. In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network. It can protect against a defect in an intermediate node, a span, a transport path segment, or an end-to-end transport path.
メッシュネットワークの線形保護 - ノード間の任意の相互接続性を持つネットワーク - は、[RFC6372]のセクション4.7で説明されています。線形保護は、迅速かつ単純な保護スイッチングを提供します。メッシュネットワークでは、線形保護は、ネットワーク内の任意のポイント間で動作できるため、非常に適切な保護メカニズムを提供します。中間ノード、スパン、輸送パスセグメント、またはエンドツーエンドの輸送パスの欠陥から保護できます。
Protection switching is a fully allocated survivability mechanism. It is fully allocated in the sense that the route and resources of the protection path are reserved for a selected working path or set of working paths. It provides a fast and simple survivability mechanism that allows the network operator to easily grasp the active state of the network and that can operate between any pair of points within the network.
保護スイッチングは、完全に割り当てられた生存可能性メカニズムです。保護パスのルートとリソースが、選択された作業パスまたは作業パスのセットのために予約されているという意味で完全に割り当てられます。ネットワークオペレーターがネットワークのアクティブ状態を簡単に把握できるようにし、ネットワーク内の任意のポイント間で動作できる高速でシンプルな生存可能性メカニズムを提供します。
As described in the Survivability Framework document [RFC6372], protection switching is applied to a protection domain. For the purposes of this document, we define the protection domain of a point-to-point LSP as consisting of two Label Edge Routers (LERs) and the transport paths that connect them (see Figure 3). For a point-to-multipoint LSP, the protection domain includes the root (or source) LER, the destination (or sink) LERs, and the transport paths that connect them.
Survivability Frameworkドキュメント[RFC6372]で説明されているように、保護スイッチングが保護ドメインに適用されます。このドキュメントの目的のために、ポイントツーポイントLSPの保護ドメインを、2つのラベルエッジルーター（LER）とそれらを接続する輸送パスで構成されるものとして定義します（図3を参照）。ポイントツーマルチポイントLSPの場合、保護ドメインには、ルート（またはソース）LER、宛先（またはシンク）レール、およびそれらを接続する輸送パスが含まれます。
In 1+1 unidirectional architecture as presented in [RFC6372], a protection transport path is dedicated to the working transport path. Normal traffic is bridged (as defined in [RFC4427]) and fed to both the working and the protection paths by a permanent bridge at the source of the protection domain. The sink of the protection domain
[RFC6372]に示されている1 1単方向アーキテクチャでは、保護輸送経路は作業輸送経路に捧げられています。通常のトラフィックは（[RFC4427]で定義されているように）ブリッジされ、保護ドメインのソースの永久橋によって作業経路と保護経路の両方に供給されます。保護ドメインのシンク
uses a selector to choose either the working or protection path from which to receive the traffic, based on predetermined criteria, e.g., server defect indication. When used for bidirectional switching the 1+1 protection architecture must also support a Protection State Coordination (PSC) protocol. This protocol is used to help coordinate between both ends of the protection domain in selecting the proper traffic flow.
セレクターを使用して、事前に決められた基準、たとえばサーバーの欠陥表示に基づいて、トラフィックを受信するために作業または保護パスを選択します。双方向の切り替えに使用される場合、1 1保護アーキテクチャは、保護状態調整（PSC）プロトコルもサポートする必要があります。このプロトコルは、適切なトラフィックフローを選択する際に、保護ドメインの両端を調整するのに役立つために使用されます。
In the 1:1 architecture, a protection transport path is dedicated to the working transport path of a single service, and the traffic is only transmitted on either the working or the protection path, by using a selector at the source of the protection domain. A selector at the sink of the protection domain then selects the path that carries the normal traffic. Since the source and sink need to be coordinated to ensure that the selector at both ends select the same path, this architecture must support a PSC protocol.
1：1のアーキテクチャでは、保護輸送パスは単一のサービスの作業輸送パスに捧げられ、保護ドメインのソースでセレクターを使用することにより、トラフィックは作業パスまたは保護パスのいずれかにのみ送信されます。保護ドメインのシンクのセレクターは、通常のトラフィックを運ぶパスを選択します。ソースとシンクを調整する必要があるため、両端のセレクターが同じパスを選択することを確認する必要があるため、このアーキテクチャはPSCプロトコルをサポートする必要があります。
The 1:n protection architecture extends the 1:1 architecture above by sharing the protection path among n services. Again, the protection path is fully allocated and disjoint from any of the n working transport paths that it is being used to protect. The normal data traffic for each service is transmitted either on the normal working path for that service or, in cases that trigger protection switching (as listed in [RFC6372]), may be sent on the protection path. The switching action is similar to the 1:1 case where a selector is used at the source. In cases where multiple working path services have triggered protection switching, it should be noted that some services, dependent upon their Service Level Agreement (SLA), may not be transmitted as a result of limited resources on the protection path. In this architecture, there may be a need for coordination of the protection switching and for resource allocation negotiation. The procedures for this are for further study and may be addressed in future documents.
1：n保護アーキテクチャは、Nサービス間で保護パスを共有することにより、上記の1：1アーキテクチャを拡張します。繰り返しますが、保護パスは完全に割り当てられ、保護に使用されているN作業輸送経路のいずれかからばらばらになります。各サービスの通常のデータトラフィックは、そのサービスの通常の作業経路または、保護スイッチングをトリガーする場合（[RFC6372]にリストされている）の場合、保護パスに送信される場合があります。スイッチングアクションは、ソースでセレクターが使用される1：1のケースに似ています。複数の作業パスサービスが保護スイッチングをトリガーした場合、サービスレベル契約（SLA）に依存する一部のサービスは、保護パス上の限られたリソースの結果として送信されない可能性があることに注意する必要があります。このアーキテクチャでは、保護スイッチングの調整とリソースの割り当て交渉が必要になる場合があります。これの手順はさらなる研究のためであり、将来の文書で対処することができます。
As was pointed out in the Survivability Framework [RFC6372] and highlighted above, there is a need for coordination between the end points of the protection domain when employing bidirectional protection schemes. This is especially true when there is a need to verify that the traffic continues to be transported on a bidirectional LSP that is co-routed.
Survivability Framework [RFC6372]で指摘され、上記で強調されたように、双方向保護スキームを使用する際には、保護ドメインのエンドポイント間に調整が必要です。これは、共同ルートの双方向LSPでトラフィックが引き続き輸送されていることを確認する必要がある場合に特に当てはまります。
The scope of this document is to present a protocol for the Protection State Coordination of Linear Protection. The protocol addresses the protection of LSPs in an MPLS-TP network as required by [RFC5654] (in particular, requirements 63-65 and 74-79) and described in [RFC6372]. The basic protocol is designed for use in conjunction
このドキュメントの範囲は、線形保護の保護状態調整のためのプロトコルを提示することです。プロトコルは、[RFC5654]で要求されているMPLS-TPネットワークでのLSPの保護に対処し（特に、要件63-65および74-79）、[RFC6372]で説明されています。基本的なプロトコルは、組み合わせて使用するように設計されています
with the 1:1 protection architecture, bidirectional protection, and for 1+1 protection of a bidirectional path (for both unidirectional and bidirectional protection switching). Applicability of the protocol for 1:1 unidirectional protection and for 1:n protection schemes may be documented in a future document and is out of scope for this document. The applicability of this protocol to additional MPLS-TP constructs and topologies may be documented in future documents.
1：1の保護アーキテクチャ、双方向保護、および双方向経路の1 1保護（単方向および双方向保護スイッチングの両方）。1：1の単方向保護と1：Nの保護スキームのプロトコルの適用性は、将来のドキュメントで文書化され、このドキュメントの範囲外です。追加のMPLS-TPコンストラクトおよびトポロジーへのこのプロトコルの適用性は、将来のドキュメントに文書化される場合があります。
While the unidirectional 1+1 protection architecture does not require the use of a coordination protocol, the protocol may be used by the ingress node of the path to notify the far-side end point that a switching condition has occurred and verify the consistency of the end-point configuration. This use may be especially useful for point-to-multipoint transport paths, that are unidirectional by definition of [RFC5654]. The use of this protocol for point-to-multipoint paths is out of scope for this document and may be addressed in a future applicability document.
単方向1 1保護アーキテクチャは調整プロトコルの使用を必要としませんが、プロトコルはパスのイングレスノードによって使用され、スイッチング条件が発生していることを通知し、終了の一貫性を検証するファーサイドエンドポイントを通知することができます。-point構成。この使用は、[RFC5654]の定義により一方向であるポイントツーマルチポイント輸送パスに特に役立つ場合があります。ポイントツーマルチポイントパスのためにこのプロトコルを使用することは、このドキュメントの範囲外であり、将来の適用性ドキュメントで対処できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
CT Channel Type DNR Do-not-Revert FS Forced Switch G-ACh Generic Associated Channel LER Label Edge Router LO Lockout of protection LSR Label Switching Router MEG Managed Entity Group MEP MEG End Point MPLS-TP Transport Profile for MPLS MS Manual Switch NR No Request OAM Operations, Administration, and Maintenance PSC Protection State Coordination Protocol S-PE Switching Provider Edge SD Signal Degrade SF Signal Fail SFc Clear Signal Fail SLA Service Level Agreement
CTチャネルタイプDNR DO-NOT-REVERT FS強制スイッチG-CHACHジェネリックチャネルLERラベルエッジROUTER保護LSRラベルスイッチングルーターMAGマネージャーグループMEG MEGエンドポイントMPLS-TPトランスポートプロファイルMPLSマニュアルスイッチNRいいえOAMの操作、管理、およびメンテナンスPSC保護状態調整プロトコルS-PEスイッチングプロバイダーEDGE SD信号SF信号失敗SFCクリアシグナル障害SLAサービスレベル契約
T-PE Terminating Provider Edge WTR Wait-to-Restore
T-PE終了プロバイダーEDGE WTTR-RESTORE
The terminology used in this document is based on the terminology defined in [RFC4427] and further adapted for MPLS-TP in [RFC6372]. In addition, we use the term "LER" to refer to an MPLS-TP Network Element, whether it is an LSR, LER, T-PE, or S-PE.
このドキュメントで使用される用語は、[RFC4427]で定義されている用語に基づいており、[RFC6372]のMPLS-TPにさらに適合しています。さらに、「LER」という用語を使用して、LSR、LER、T-PE、またはS-PEであろうと、MPLS-TPネットワーク要素を参照します。
Protection switching processes the local triggers described in requirements 74-79 of [RFC5654] together with inputs received from the far-end LER. Based on these inputs, the LER will take certain protection switching actions, e.g., switching the selector to transmit on the working or protection path for 1:1 protection or switching the selector to receive the traffic for either 1:1 or 1+1 protection and transmit different protocol messages.
保護スイッチングプロセス[RFC5654]の要件74-79で説明されているローカルトリガーと、ファーエンドLERから受信した入力。これらの入力に基づいて、LERは特定の保護スイッチングアクションを実行します。たとえば、セレクターを切り替えて作業または保護パスを1：1保護または保護パスで送信するか、セレクターを切り替えて1：1または1 1の保護と1つの保護のいずれかのトラフィックを受信します。異なるプロトコルメッセージを送信します。
The following figure shows the logical decomposition of the Protection State Control logic into different logical processing units. These processing units are presented in subsequent subsections of this document. This logical decomposition is only intended for descriptive purposes; any implementation that produces the external behavior described in Section 4 is acceptable.
次の図は、さまざまな論理処理ユニットへの保護状態制御論理の論理的分解を示しています。これらの処理ユニットは、このドキュメントの後続のサブセクションで提示されます。この論理的な分解は、記述的な目的のみを目的としています。セクション4で説明されている外部動作を生成する実装は受け入れられます。
Server Indication Control-Plane Indication
-----------------+ +-------------
Operator Command | | OAM Indication
----------------+ | | +---------------
| | | |
V V V V
+---------------+ +-------+
| Local Request |<--------| WTR |
| logic |WTR Exps | Timer |
+---------------+ +-------+
| ^
Highest local|request |
V | Start/Stop
+-----------------+ |
Remote PSC | PSC Control |------------+
------------>| logic |
Request +-----------------+
|
| Action +------------+
+---------------->| Message |
| Generator |
+------------+
|
Output PSC | Message
V
Figure 1: Protection State Control Logic
図1：保護状態制御ロジック
Figure 1 describes the logical architecture of the protection switching control. The Local Request logic unit accepts the triggers from the OAM, server layer, external operator commands, local control plane (when present), and the Wait-to-Restore timer. By considering all of these local request sources, it determines the highest priority local request. This high-priority request is passed to the PSC Control logic, that will cross-check this local request with the information received from the far-end LER. The PSC Control logic uses this input to determine what actions need to be taken, e.g., local actions at the LER, or what message should be sent to the far-end LER, and the current status of the protection domain.
図1は、保護スイッチング制御の論理アーキテクチャを説明しています。ローカルリクエストロジックユニットは、OAM、サーバーレイヤー、外部演算子コマンド、ローカルコントロールプレーン（存在する場合）、および待機対象タイマーからのトリガーを受け入れます。これらのローカルリクエストソースのすべてを考慮することにより、最優先のローカルリクエストを決定します。この優先度の高い要求は、PSC制御ロジックに渡され、このローカルリクエストがファーエンドLERから受信された情報をクロスチェックします。PSC制御ロジックは、この入力を使用して、どのアクションを実行する必要があるかを決定します。たとえば、LERでのローカルアクション、またはファーエンドLERに送信するメッセージ、および保護ドメインの現在のステータスを決定します。
The Local Request logic processes input triggers from five sources.
ローカルリクエストロジックプロセスは、5つのソースからトリガーを入力します。
o Operator command - the network operator may issue local administrative commands on the LER that trigger protection switching. The commands Forced Switch, Manual Switch, Clear, Lockout of protection (defined in [RFC4427] as Forced switch-over, Manual switch-over, Clear, and Lockout of recovery LSP/span, respectively) MUST be supported. An implementation MAY provide additional commands for operator use; providing that these commands do not introduce incompatible behavior between two arbitrary implementations, they are outside the scope of this document. For example, an implementation could provide a command to manually set off a "WTR Expires" trigger (see below) input without waiting for the duration of the WTR timer; as this merely hastens the transition from one state to another and has no impact on the state machine itself, it would be perfectly valid.
o オペレーターコマンド - ネットワークオペレーターは、保護スイッチングをトリガーするLERでローカル管理コマンドを発行する場合があります。コマンドは、強制スイッチ、[RFC4427]で強制スイッチオーバー、マニュアルスイッチオーバー、クリア、および回復LSP/SPANのロックアウトとして強制スイッチ、マニュアルスイッチ、クリア、ロックアウト（[RFC4427]で定義されています）をサポートする必要があります。実装は、オペレーターの使用に追加のコマンドを提供する場合があります。これらのコマンドが2つのarbitrary意的な実装の間に互換性のない動作を導入しないことを規定すると、それらはこのドキュメントの範囲外にあります。たとえば、実装は、WTRタイマーの期間を待たずに「WTRの有効期限が切れる」トリガー（以下を参照）入力を手動でオフにするコマンドを提供できます。これは単にある状態から別の状態への移行を早め、状態マシン自体に影響を与えないため、完全に有効です。
o Server-layer alarm indication - the underlying server layer of the network detects failure conditions at the underlying layer and may issue an indication to the MPLS-TP layer. The server layer may employ its own protection switching mechanism; therefore, this input MAY be controlled by a hold-off timer that SHOULD be configurable by the network operator. The hold-off timer is described in greater detail in [RFC6372].
o サーバーレイヤーアラーム表示 - ネットワークの基礎となるサーバーレイヤーは、基礎となる層の故障条件を検出し、MPLS-TPレイヤーの表示を発行する可能性があります。サーバーレイヤーは、独自の保護スイッチングメカニズムを使用する場合があります。したがって、この入力は、ネットワークオペレーターが構成可能なホールドオフタイマーによって制御される場合があります。ホールドオフタイマーについては、[RFC6372]でより詳細に説明されています。
o Control-Plane Indication - if there is a control plane active in the network (either signaling or routing), it MAY trigger protection switching based on conditions detected by the control plane. If the control plane is based on GMPLS [RFC3945], then the recovery process SHALL comply with the process described in [RFC4872] and [RFC4873].
o コントロールプレーンの表示 - ネットワークにアクティブなコントロールプレーンがある場合（信号またはルーティング）、コントロールプレーンによって検出された条件に基づいて保護スイッチングをトリガーする場合があります。制御面がGMPL [RFC3945]に基づいている場合、回復プロセスは[RFC4872]および[RFC4873]に記載されているプロセスに準拠するものとします。
o OAM indication - OAM fault management or performance measurement tools may detect a failure or degrade condition on either the working or protection transport path, and this MUST input an indication to the Local Request logic.
o OAMの適応 - OAM障害管理またはパフォーマンス測定ツールは、作業または保護輸送パスの障害または劣化状態を検出する場合があり、これはローカルリクエストロジックに表示を入力する必要があります。
o WTR Expires - The Wait-to-Restore timer is used in conjunction with recovery from failure conditions on the working path in revertive mode. The timer SHALL signal the PSC control process when it expires, and the end point SHALL revert to the normal transmission of the user data traffic.
o WTRの有効期限 - 待機対象タイマーは、リバートモードの作業経路での故障条件からの回復と併せて使用されます。タイマーは、PSC制御プロセスが期限切れになったときに信号を送るものとし、エンドポイントはユーザーデータトラフィックの通常の送信に戻ります。
The input from these sources SHOULD be retained persistently for the duration of the condition that initiated the trigger. The Local Request logic processes these different input sources and, based on
これらのソースからの入力は、トリガーを開始した状態の期間中、持続的に保持する必要があります。ローカルリクエストロジックは、これらの異なる入力ソースを処理し、に基づいて
the priorities between them (see Section 4.3.2), produces a current local request. If more than one local input source generates a trigger, then the Local Request logic selects the higher priority indicator and ignores any lower priority indicator. As a result, there is a single current local request that is passed to the PSC Control logic. The different local requests that may be output from the Local Request logic are as follows:
それらの間の優先順位（セクション4.3.2を参照）は、現在のローカルリクエストを作成します。複数のローカル入力ソースがトリガーを生成した場合、ローカルリクエストロジックはより高い優先度インジケーターを選択し、優先度の低いインジケーターを無視します。その結果、PSC制御ロジックに渡される単一の現在のローカル要求があります。ローカルリクエストロジックから出力される可能性のあるさまざまなローカルリクエストは次のとおりです。
o Clear - if the operator cancels an active local administrative command, i.e., LO/FS/MS.
o クリア - オペレーターがアクティブなローカル管理コマンド、つまりLO/FS/MSをキャンセルした場合。
o Lockout of protection (LO) - if the operator requested to prevent switching data traffic to the protection path, for any purpose.
o 保護のロックアウト（LO） - オペレーターがデータのトラフィックを保護パスに切り替えるのを防ぐように要求した場合、あらゆる目的で。
o Signal Fail (SF) - if any of the server-layer, control-plane, or OAM indications signaled a failure condition on either the protection path or one of the working paths.
o 信号障害（SF） - サーバーレイヤー、コントロールプレーン、またはOAM適応症のいずれかが、保護パスまたは作業パスのいずれかの障害条件を示した場合。
o Signal Degrade (SD) - if any of the server-layer, control-plane, or OAM indications signaled a degraded transmission condition on either the protection path or one of the working paths. The determination and actions for SD are for further study and may appear in a separate document. All references to SD input are placeholders for this extension.
o Signal Degrade（SD） - サーバー層、コントロールプレーン、またはOAM適応症のいずれかが、保護パスまたは作業パスのいずれかで劣化した透過条件を示した場合。SDの決定と行動はさらなる研究のためであり、別の文書に表示される場合があります。SD入力へのすべての参照は、この拡張機能のプレースホルダーです。
o Clear Signal Fail (SFc) - if all of the server-layer, control-plane, or OAM indications are no longer indicating a failure condition on a path that was previously indicating a failure condition.
o Clear Signal Fail（SFC） - すべてのサーバー層、コントロールプレーン、またはOAM適応症が、以前に障害条件を示していたパスの障害条件を示しなくなった場合。
o Forced Switch (FS) - if the operator requested that traffic be switched from one of the working paths to the protection path.
o 強制スイッチ（FS） - オペレーターが、作業パスの1つから保護パスにトラフィックを切り替えることを要求した場合。
o Manual Switch (MS) - if the operator requested that traffic be switched from the working path to the protection path. This is only relevant if there is no currently active fault condition or operator command.
o マニュアルスイッチ（MS） - オペレーターがトラフィックを動作パスから保護パスに切り替えることを要求した場合。これは、現在アクティブな障害状態または演算子コマンドがない場合にのみ関連します。
o WTR Expires (WTRExp) - generated by the WTR timer completing its period.
o WTR有効期限（WTREXP） - WTRタイマーによって生成された期間が完了します。
If none of the input sources have generated any triggers, then the Local Request logic should generate a No Request (NR) as the current local request.
入力ソースのいずれもトリガーを生成していない場合、ローカルリクエストロジックは、現在のローカルリクエストとしてNO要求（NR）を生成する必要があります。
In addition to the local requests, generated as a result of the local triggers, indicated in the previous subsection, the PSC Control logic SHALL accept PSC messages from the far-end LER of the transport path. Remote messages indicate the status of the transport path from the viewpoint of the far-end LER. These messages may drive state changes on the local MEP, as defined later in this document. When using 1+1 unidirectional protection, an LER that receives a remote request SHALL NOT perform any protection switching action, i.e., will continue to select traffic from the working path and transport traffic on both paths.
以前のサブセクションで示されたローカルトリガーの結果として生成されたローカルリクエストに加えて、PSC制御ロジックは、輸送パスの遠端からのPSCメッセージを受け入れるものとします。リモートメッセージは、遠端のLERの視点からの輸送パスのステータスを示します。これらのメッセージは、このドキュメントの後半で定義されているように、ローカルMEPの状態の変更を促進する場合があります。1 1単方向保護を使用する場合、リモートリクエストを受信するLERは、保護スイッチングアクションを実行してはなりません。つまり、作業経路からトラフィックを選択し続け、両方のパスのトラフィックを輸送します。
The following remote requests may be received by the PSC process:
次のリモートリクエストは、PSCプロセスによって受信される場合があります。
o Remote LO - indicates that the remote end point is in Unavailable state due to a Lockout of protection operator command.
o リモートLO-保護オペレーターコマンドのロックアウトにより、リモートエンドポイントが利用できない状態にあることを示します。
o Remote SF - indicates that the remote end point has detected a Signal Fail condition on one of the transport paths in the protection domain. This remote message includes an indication of which transport path is affected by the SF condition. In addition, it should be noted that the SF condition may be either a unidirectional or a bidirectional failure, even if the transport path is bidirectional.
o リモートSF-リモートエンドポイントが保護ドメイン内の輸送パスの1つで信号障害条件を検出したことを示します。このリモートメッセージには、どの輸送経路がSF条件の影響を受けるかを示すことが含まれています。さらに、輸送経路が双方向であっても、SF条件は単方向または双方向の故障である可能性があることに注意する必要があります。
o Remote SD - indicates that the remote end point has detected a Signal Degrade condition on one of the transport paths in the protection domain. This remote message includes an indication of which transport path is affected by the SD condition. In addition, it should be noted that the SD condition may be either a unidirectional or a bidirectional failure, even if the transport path is bidirectional.
o リモートSD-リモートエンドポイントが、保護ドメイン内の輸送パスの1つで信号分解条件を検出したことを示します。このリモートメッセージには、どの輸送経路がSD条件の影響を受けるかを示すことが含まれています。さらに、輸送経路が双方向であっても、SD条件は単方向または双方向の障害である可能性があることに注意する必要があります。
o Remote FS - indicates that the remote end point is operating under an operator command to switch the traffic to the protection path.
o リモートFS-リモートエンドポイントがオペレーターコマンドの下で動作していることを示して、トラフィックを保護パスに切り替えます。
o Remote MS - indicates that the remote end point is operating under an operator command to switch the traffic from the working path to the protection path.
o リモートMS-リモートエンドポイントがオペレーターコマンドの下で動作していることを示し、トラフィックを作業パスから保護パスに切り替えます。
o Remote WTR - indicates that the remote end point has determined that the failure condition has recovered and has started its WTR timer in preparation for reverting to the Normal state.
o リモートWTR-リモートエンドポイントが故障条件が回復したことを決定し、通常の状態に戻すためにWTRタイマーを開始したことを示します。
o Remote DNR - indicates that the remote end point has determined that the failure condition has recovered and will continue transporting traffic on the protection path due to operator configuration that prevents automatic reversion to the Normal state.
o リモートDNR-リモートエンドポイントが故障条件が回復したことを決定し、通常の状態への自動回復を防ぐオペレーターの構成により、保護パスのトラフィックの輸送を継続することを示します。
o Remote NR - indicates that the remote end point has no abnormal condition to report.
o リモートNR-リモートエンドポイントには、報告する異常な条件がないことを示します。
The PSC Control logic accepts the following input:
PSC制御ロジックは、次の入力を受け入れます。
a. the current local request output from the Local Request logic (see Section 3.1),
a. ローカルリクエストロジックからの現在のローカルリクエスト出力（セクション3.1を参照）、
b. the remote request message from the remote end point of the transport path (see Section 3.2), and
b. トランスポートパスのリモートエンドポイントからのリモートリクエストメッセージ（セクション3.2を参照）、および
c. the current state of the PSC Control logic (maintained internally by the PSC Control logic).
c. PSC制御ロジックの現在の状態（PSC制御ロジックによって内部的に維持されています）。
Based on the priorities between the different inputs, the PSC Control logic determines the new state of the PSC Control logic and what actions need to be taken.
異なる入力間の優先順位に基づいて、PSC制御ロジックは、PSC制御ロジックの新しい状態と、実行する必要があるものを決定します。
The new state information is retained by the PSC Control logic, while the requested action should be sent to the PSC Message Generator (see Section 3.4) to generate and transmit the proper PSC message to be transmitted to the remote end point of the protection domain.
新しい状態情報はPSC制御ロジックによって保持されますが、要求されたアクションはPSCメッセージジェネレーター（セクション3.4を参照）に送信して、保護ドメインのリモートエンドポイントに送信される適切なPSCメッセージを生成および送信する必要があります。
Based on the action output from the PSC Control logic, this unit formats the PSC protocol message that is transmitted to the remote end point of the protection domain. This message may either be the same as the previously transmitted message or change when the PSC control state (see Section 3.6) has changed. The messages are transmitted as described in Section 4.1 of this document.
PSC制御ロジックからのアクション出力に基づいて、このユニットは、保護ドメインのリモートエンドポイントに送信されるPSCプロトコルメッセージをフォーマットします。このメッセージは、PSC制御状態（セクション3.6を参照）が変更された場合に、以前に送信されたメッセージと同じであるか、変更された場合と同じです。メッセージは、このドキュメントのセクション4.1で説明されているように送信されます。
The WTR timer is used to delay reversion to Normal state when recovering from a failure condition on the working path and the protection domain is configured for revertive behavior. The length of the timer may be provisioned by the operator. The WTR may be in
WTRタイマーは、作業経路の故障条件から回復する際に正常状態に逆転を遅らせるために使用され、保護ドメインは戻る動作のために構成されます。タイマーの長さは、オペレーターによってプロビジョニングされる場合があります。WTRが入っている可能性があります
one of two states: Running or Stopped. The control of the WTR timer is managed by the PSC Control logic, by use of internal signals to start and stop, i.e., reset, the WTR timer.
2つの州の1つ：実行または停止。WTRタイマーの制御は、内部信号を使用して開始および停止、つまりWTRタイマーをリセットすることにより、PSC制御ロジックによって管理されます。
If the WTR timer expires prior to being stopped, it SHALL generate a WTR Expires local signal that is processed by the Local Request logic. If the WTR timer is running, sending a Stop command SHALL reset the timer, and put the WTR timer into Stopped state, but SHALL NOT generate a WTR Expires local signal. If the WTR timer is stopped, a Stop command SHALL be ignored.
停止する前にWTRタイマーが期限切れになった場合、ローカルリクエストロジックによって処理されるローカル信号の有効期限が切れるWTRが生成されます。WTRタイマーが実行されている場合、STOPコマンドの送信はタイマーをリセットし、WTRタイマーを停止状態に配置する必要がありますが、WTRが生成してはなりません。WTRタイマーが停止した場合、停止コマンドは無視されます。
The PSC Control logic should maintain information on the current state of the protection domain. Information on the state of the domain is maintained by each LER within the protection domain. The state information would include information of the current state of the protection domain, an indication of the cause for the current state (e.g., unavailable due to local LO command, protecting due to remote FS), and, for each LER, should include an indication if the state is related to a remote or local condition.
PSC制御ロジックは、保護ドメインの現在の状態に関する情報を維持する必要があります。ドメインの状態に関する情報は、保護ドメイン内の各LERによって維持されます。状態情報には、保護ドメインの現状の情報、現在の状態（例：リモートFSによる保護、保護）の原因の兆候、およびそれぞれのLERには、含まれる必要があります。状態がリモートまたはローカルな状態に関連しているかどうかを示しています。
It should be noted that when referring to the "transport" of the data traffic, in the following descriptions and later in the document that the data will be transmitted on both the working and the protection paths when using 1+1 protection, and on either the working or the protection path exclusively when using 1:1 protection. When using 1+1 protection, the receiving LER should select the proper transmission, according to the state of the protection domain.
データトラフィックの「輸送」を参照する場合、以下の説明で、後でドキュメントで、1 1保護を使用する場合、およびどちらかの場合、データが作業経路と保護パスの両方で送信されることに注意する必要があります。1：1の保護を使用する場合のみ、作業または保護パス。1 1保護を使用する場合、受信LERは、保護ドメインの状態に従って適切な伝送を選択する必要があります。
The protection domain states that are supported by the PSC Control logic are as follows:
PSC制御ロジックによってサポートされている保護ドメインは次のとおりです。
o Normal state - Both the protection and working paths are fully allocated and active, data traffic is being transported over (or selected from) the working path, and no trigger events are reported within the domain.
o 通常の状態 - 保護パスと作業経路の両方が完全に割り当てられ、アクティブになり、データトラフィックは作業経路の上に輸送されます（または選択されています）。ドメイン内でトリガーイベントは報告されません。
o Unavailable state - The protection path is unavailable -- either as a result of an operator Lockout command or a failure condition detected on the protection path.
o 利用できない状態 - 保護パスは利用できません - オペレーターのロックアウトコマンドの結果、または保護パスで検出された障害条件のいずれかです。
o Protecting failure state - The working path has reported a failure/degrade condition and the user traffic is being transported (or selected) on the protection path.
o 障害状態の保護 - 作業経路は、故障/劣化状態を報告し、ユーザートラフィックは保護パスで輸送（または選択されています）。
o Protecting administrative state - The operator has issued a command switching the user traffic to the protection path.
o 管理状態の保護 - オペレーターは、ユーザートラフィックを保護パスに切り替えるコマンドを発行しました。
o Wait-to-Restore state - The protection domain is recovering from an SF/SD condition on the working path that is being controlled by the Wait-to-Restore (WTR) timer.
o 待機対策状態 - 保護ドメインは、待機対策（WTR）タイマーによって制御されている作業経路のSF/SD条件から回復しています。
o Do-not-Revert state - The protection domain has recovered from a Protecting state, but the operator has configured the protection domain not to automatically revert to the Normal state upon recovery. The protection domain SHALL remain in this state until the operator issues a command to revert to the Normal state or there is a new trigger to switch to a different state.
o do-not-revert状態 - 保護ドメインは保護状態から回復しましたが、オペレーターは回復時に自動的に正常状態に戻らないように保護ドメインを構成しました。保護ドメインは、オペレーターがコマンドを発行して通常の状態に戻るか、別の状態に切り替える新しいトリガーがあるまで、この状態にとどまります。
See Section 4.3.3 for details on what actions are taken by the PSC Process logic for each state and the relevant input.
各状態のPSCプロセスロジックと関連する入力の詳細については、セクション4.3.3を参照してください。
An end point may be in a given state as a result of either a local input indicator (e.g., OAM, WTR timer) or as a result of receiving a PSC message from the far-end LER. If the state is entered as a result of a local input indicator, then the state is considered a local state. If the state is entered as a result of a PSC message, in the absence of a local input, then the state is considered a remote state. This differentiation affects how the LER reacts to different inputs, as described in Section 4.3.3. The PSC Control logic should maintain, together with the current protection domain state, an indication of whether this is a local or remote state, for this LER.
エンドポイントは、ローカル入力インジケータ（OAM、WTRタイマーなど）のいずれかの結果として、またはファーエンドLERからPSCメッセージを受信した結果として、特定の状態にある場合があります。ローカル入力インジケータの結果として状態が入力された場合、状態は地方の状態と見なされます。PSCメッセージの結果として状態が入力された場合、ローカル入力がない場合、状態はリモート状態と見なされます。この分化は、セクション4.3.3で説明されているように、LERが異なる入力にどのように反応するかに影響します。PSC制御ロジックは、現在の保護ドメイン状態とともに、これがローカル状態であるかリモート状態であるかを維持する必要があります。
In any instance where the LER has both a local and remote indicator that cause the protection domain to enter a particular state, then the state is considered a local state, regardless of the order in which the indicators were processed. If, however, the LER has local and remote indicators that would cause the protection domain to enter different states, e.g., a local SF on working and a remote Lockout of protection message, then the input with the higher priority (see Section 4.3.2) will be the deciding factor and the source of that indicator will determine whether it is local or remote. In the given example, the result would be a Remote Unavailable state transmitting PSC messages that indicate an SF condition on the working path and that the protection path is not being used to transport protected traffic (as described in the next section).
LERには、保護ドメインが特定の状態に入る原因となるローカルおよびリモートインジケーターの両方がある場合、インジケータが処理された順序に関係なく、状態はローカル状態と見なされます。ただし、LERには、保護ドメインが異なる状態に入るようになるローカルおよびリモートのインジケータがある場合、たとえば、動作に関するローカルSFと保護メッセージのリモートロックアウト、より高い優先度を持つ入力を持つ場合（セクション4.3.2を参照してください。）決定要因となり、そのインジケーターのソースは、それがローカルかリモートかを決定します。指定された例では、結果は、作業経路のSF条件を示すPSCメッセージを送信するリモートのない状態で、保護パスが保護されたトラフィックを輸送するために使用されていないことになります（次のセクションで説明されているように）。
Bidirectional protection switching, as well as unidirectional 1:1 protection, requires coordination between the two end points in determining which of the two possible paths, the working or protection path, is transmitting the data traffic in any given
双方向保護スイッチング、ならびに一方向1：1保護には、2つの可能なパスのうちどれが作業または保護パスのどれが特定されているかを決定する際に、2つのエンドポイント間の調整が必要です。
situation. When protection switching is triggered as described in Section 3, the end points must inform each other of the switchover from one path to the other in a coordinated fashion.
状況。セクション3で説明されているように保護スイッチングがトリガーされる場合、エンドポイントは、調整された方法であるパスから他のパスへのスイッチオーバーを互いに通知する必要があります。
There are different possibilities for the type of coordinating protocol. One possibility is a two-phased coordination in which the LER that is initiating the protection switching sends a protocol message indicating the switch but the actual switchover is performed only after receiving an 'Ack' from the far-end LER. The other possibility is a single-phased coordination, in which the initiating LER performs the protection switchover to the alternate path and informs the far-end LER of the switch, and the far-end LER will complete the switchover.
調整プロトコルのタイプにはさまざまな可能性があります。1つの可能性は、保護スイッチングを開始しているLERがスイッチを示すプロトコルメッセージを送信する2段階の調整ですが、実際のスイッチオーバーは、ファーエンドLERから「ACK」を受信した後にのみ実行されます。もう1つの可能性は、単一の段階的な調整であり、開始LERが代替パスへの保護スイッチオーバーを実行し、スイッチのファーエンドLERを通知し、ファーエンドLERがスイッチオーバーを完了します。
This protocol is a single-phased protocol, as described above. In the following subsections, we describe the protocol messages that are used between the two end points of the protection domain.
このプロトコルは、上記のように単一のプロトコルです。次のサブセクションでは、保護ドメインの2つのエンドポイント間で使用されるプロトコルメッセージについて説明します。
The PSC control packets SHALL be transmitted over the protection path only. This allows the transmission of the messages without affecting the normal data traffic in the most prevalent case, i.e., the Normal state. In addition, limiting the transmission to a single path avoids possible conflicts and race conditions that could develop if the PSC messages were sent on both paths.
PSC制御パケットは、保護パスのみに送信されます。これにより、最も一般的な場合、つまり通常の状態で通常のデータトラフィックに影響を与えることなく、メッセージを送信できます。さらに、伝送を単一のパスに制限すると、PSCメッセージが両方のパスで送信された場合に発生する可能性のある競合と人種条件が回避されます。
When the protection domain state is changed due to a local input, three PSC messages SHALL be transmitted as quickly as possible, to allow for rapid protection switching. This set of three rapid messages allows for fast protection switching even if one or two of these packets are lost or corrupted. When the protection domain state changes due to a remote message, the LER SHOULD send the three rapid messages. However, when the LER transfers from WTR state to Normal state as a result of a remote NR message, the three rapid messages SHALL be transmitted. After the transmission of the three rapid messages, the LER MUST retransmit the most recently transmitted PSC message on a continual basis.
局所入力のために保護ドメイン状態が変更されると、迅速な保護スイッチングを可能にするために、3つのPSCメッセージをできるだけ早く送信する必要があります。この3つの迅速なメッセージのセットにより、これらのパケットの1つまたは2つが紛失または破損している場合でも、高速保護スイッチングが可能になります。リモートメッセージのために保護ドメイン状態が変更された場合、LERは3つの迅速なメッセージを送信する必要があります。ただし、リモートNRメッセージの結果としてLERがWTR状態から正常状態に転送される場合、3つの迅速なメッセージが送信されます。3つの迅速なメッセージを送信した後、LERは最近送信されたPSCメッセージを継続的に再送信する必要があります。
Both the default frequency of the three rapid messages as well as the default frequency of the continual message transmission SHALL be configurable by the operator. The actual frequencies used MAY be configurable, at the time of establishment, for each individual protected LSP. For management purposes, the operator SHOULD be able to retrieve the current default frequency values as well as the actual values for any specific LSP. For protection switching within 50 ms, it is RECOMMENDED that the default interval of the first three rapid PSC messages SHOULD be no longer than 3.3 ms. Using this
3つの迅速なメッセージのデフォルト周波数と、継続的なメッセージ送信のデフォルト周波数の両方が、演算子が構成可能でなければなりません。使用される実際の周波数は、個々の保護されたLSPごとに設立時に構成可能である場合があります。管理目的のために、オペレーターは、特定のLSPの実際の値と同様に現在のデフォルト周波数値を取得できる必要があります。50ミリ秒以内に保護スイッチングを行うには、最初の3つのRapid PSCメッセージのデフォルト間隔を3.3ミリ秒以内にすることをお勧めします。これを使用します
frequency would allow the far-end to be guaranteed of receiving the trigger indication within 10 ms and completion of the switching operation within 50 ms. Subsequent messages SHOULD be continuously transmitted with a default interval of 5 seconds. The purpose of the continual messages is to verify that the PSC session is still alive.
周波数により、ファーエンドが10ミリ秒以内にトリガー表示を受信し、50ミリ秒以内にスイッチング操作が完了することが保証されます。後続のメッセージは、5秒のデフォルト間隔で継続的に送信する必要があります。継続的なメッセージの目的は、PSCセッションがまだ生きていることを確認することです。
If no valid PSC message is received, over a period of several continual messages intervals, the last valid received message remains applicable.
有効なPSCメッセージが受信されない場合、いくつかの継続的なメッセージ間隔の期間にわたって、最後に有効な受信メッセージが適用されたままです。
The protocol messages SHALL be sent over the G-ACh as described in [RFC5586]. There is a single channel type for the set of PSC messages. The actual message function SHALL be identified by the Request field of the ACH payload as described below.
[RFC5586]に記載されているように、プロトコルメッセージはG-achを介して送信されます。PSCメッセージのセットには、単一のチャネルタイプがあります。実際のメッセージ関数は、以下に説明するように、ACHペイロードの要求フィールドによって識別されるものとします。
The channel type for the PSC messages SHALL be PSC-CT=0x0024.
PSCメッセージのチャネルタイプは、PSC-CT = 0x0024でなければなりません。
The following figure shows the format for the complete PSC message.
次の図は、完全なPSCメッセージの形式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | PSC-CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request|PT |R| Reserved1 | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Length | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of PSC Packet with a G-ACh Header
図2：G-achヘッダーを備えたPSCパケットの形式
Where:
ただし：
o Both Reserved1 and Reserved2 fields MUST be set to 0 and ignored upon receipt.
o 予約済み1と保存2フィールドの両方を0に設定し、受領時に無視する必要があります。
o The following subsections describe the remaining fields of the PSC payload.
o 次のサブセクションでは、PSCペイロードの残りのフィールドについて説明します。
The Ver field identifies the version of the protocol. For this version of the document, the value SHALL be 1.
Verフィールドは、プロトコルのバージョンを識別します。このバージョンのドキュメントの場合、値は1になります。
The PSC protocol SHALL support transmission of the following requests between the two end points of the protection domain:
PSCプロトコルは、保護ドメインの2つのエンドポイント間の次の要求の送信をサポートするものとします。
o (14) Lockout of protection - indicates that the end point has disabled the protection path as a result of an administrative command. Both the FPath and Path fields SHALL be set to 0.
o （14）保護のロックアウト - エンドポイントが管理コマンドの結果として保護パスを無効にしたことを示します。FPATHフィールドとパスフィールドの両方を0に設定する必要があります。
o (12) Forced Switch - indicates that the transmitting end point has switched traffic to the protection path as a result of an administrative command. The FPath field SHALL indicate that the working path is being blocked (i.e., FPath set to 1), and the Path field SHALL indicate that user data traffic is being transported on the protection path (i.e., Path set to 1).
o （12）強制スイッチ - 送信エンドポイントが、管理コマンドの結果としてトラフィックを保護パスに切り替えたことを示します。FPATHフィールドは、作業経路がブロックされていること（つまり、FPATが1に設定されている）を示し、パスフィールドは、ユーザーデータトラフィックが保護パスで輸送されていることを示します（つまり、1に設定されたパス）。
o (10) Signal Fail - indicates that the transmitting end point has identified a signal fail condition on either the working or protection path. The FPath field SHALL identify the path that is reporting the failure condition (i.e., if protection path, then FPath is set to 0; if working path, then FPath is set to 1), and the Path field SHALL indicate where the data traffic is being transported (i.e., if protection path is blocked, then Path is set to 0; if working path is blocked, then Path is set to 1).
o （10）信号障害 - 送信エンドポイントが、作業パスまたは保護パスのいずれかで信号障害条件を特定したことを示します。FPATHフィールドは、故障条件を報告しているパスを識別します（つまり、保護パスの場合、FPATは0に設定されます。動作パスが1に設定されます。輸送される（つまり、保護パスがブロックされている場合、パスが0に設定されます。作業経路がブロックされている場合、パスは1に設定されます）。
o (7) Signal Degrade - indicates that the transmitting end point has identified a degradation of the signal, or integrity of the packet transmission on either the working or protection path. This request is presented here only as a placeholder. The specifics for the method of identifying this degradation is out of scope for this document. The details of the actions to be taken for this situation are left for future specification.
o （7）信号の劣化 - 送信エンドポイントが、作業パスまたは保護パスでの信号の分解、またはパケット伝送の整合性を特定したことを示します。このリクエストは、ここではプレースホルダーとしてのみ表示されます。この劣化を特定する方法の詳細は、このドキュメントの範囲外です。この状況のためにとられるアクションの詳細は、将来の仕様のために残されています。
o (5) Manual Switch - indicates that the transmitting end point has switched traffic to the protection path as a result of an administrative Manual Switch command. The FPath field SHALL indicate that the working path is being blocked (i.e., FPath set to 1), and the Path field SHALL indicate that user data traffic is being transported on the protection path (i.e., Path set to 1).
o （5）手動スイッチ - 送信エンドポイントが、管理マニュアルスイッチコマンドの結果としてトラフィックを保護パスに切り替えたことを示します。FPATHフィールドは、作業経路がブロックされていること（つまり、FPATが1に設定されている）を示し、パスフィールドは、ユーザーデータトラフィックが保護パスで輸送されていることを示します（つまり、1に設定されたパス）。
o (4) Wait-to-Restore - indicates that the transmitting end point is recovering from a failure condition of the working path and has started the Wait-to-Restore timer. FPath SHALL be set to 0 and ignored upon receipt. Path SHALL indicate the working path that is currently being protected (i.e., Path set to 1).
o （4）待機対策 - 送信エンドポイントが作業経路の故障条件から回復しており、待機対策タイマーを開始したことを示します。fpathは0に設定され、受領時に無視されます。パスは、現在保護されている作業経路（つまり、1に設定されたパス）を示すものとします。
o (1) Do-not-Revert - indicates that the transmitting end point has recovered from a failure/blocked condition, but due to the local settings, is requesting that the protection domain continues to transport the data as if it is in a protecting state, rather than revert to the Normal state. FPath SHALL be set to 0 and ignored upon receipt. Path SHALL indicate the working path that is currently being protected (i.e., Path set to 1).
o （1）do-not-revert-送信エンドポイントが故障/ブロックされた状態から回復したことを示しますが、ローカル設定により、保護ドメインは保護状態にあるかのようにデータを輸送し続けることを要求しています。、通常の状態に戻るのではなく。fpathは0に設定され、受領時に無視されます。パスは、現在保護されている作業経路（つまり、1に設定されたパス）を示すものとします。
o (0) No Request - indicates that the transmitting end point has nothing to report, FPath and Path fields SHALL be set according to the transmission state of the end point, see Section 4.3.3 for detailed scenarios.
o （0）要求なし - 送信エンドポイントには報告するものがないことを示します。FPATHとパスフィールドは、エンドポイントの伝送状態に従って設定するものとします。詳細なシナリオについてはセクション4.3.3を参照してください。
All other values are for future extensions (to be administered by IANA) and SHALL be ignored upon receipt.
他のすべての値は、将来の拡張機能（IANAによって管理される）用であり、受領時に無視されます。
The PT field indicates the currently configured protection architecture type, this SHOULD be validated to be consistent for both ends of the protection domain. If an inconsistency is detected, then an alarm SHALL be sent to the management system. The following are the possible values:
PTフィールドは、現在構成されている保護アーキテクチャタイプを示します。これは、保護ドメインの両端について一貫性があるように検証する必要があります。矛盾が検出された場合、アラームが管理システムに送信されます。以下は考えられる値です。
o 3: bidirectional switching using a permanent bridge
o 3：永久橋を使用した双方向の切り替え
o 2: bidirectional switching using a selector bridge
o 2：セレクターブリッジを使用した双方向スイッチング
o 1: unidirectional switching using a permanent bridge
o 1：永続的なブリッジを使用した単方向スイッチング
o 0: for future extensions
o 0：将来の拡張機能
As described in the Introduction (Section 1.1) a 1+1 protection architecture is characterized by the use of a permanent bridge at the source node, whereas the 1:1 and 1:n protection architectures are characterized by the use of a selector bridge at the source node.
はじめに（セクション1.1）で説明されているように、1 1保護アーキテクチャは、ソースノードでの永続的なブリッジの使用によって特徴付けられますが、1：1および1：nの保護アーキテクチャは、セレクターブリッジの使用によって特徴付けられます。ソースノード。
This field indicates that the transmitting end point is configured to work in revertive mode. If there is an inconsistency between the two end points, i.e., one end point is configured for revertive action and the second end point is in non-revertive mode, then the management system SHOULD be notified. The following are the possible values:
このフィールドは、送信エンドポイントがリバートモードで動作するように構成されていることを示しています。2つのエンドポイントの間に矛盾がある場合、つまり1つのエンドポイントが戻るアクション用に構成され、2番目のエンドポイントが非反転モードである場合、管理システムに通知する必要があります。以下は考えられる値です。
o 0 - non-revertive mode
o 0-非応答モード
o 1 - revertive mode
o 1-リバートモード
The FPath field indicates which path (i.e., working or protection) is identified to be in a fault condition or affected by an administrative command, when a fault or command is indicated by the Request field to be in effect. The following are the possible values:
FPATHフィールドは、障害またはコマンドがリクエストフィールドで有効であると示されている場合、どの経路（つまり、動作または保護）が障害状態にあるか、管理コマンドの影響を受けているかを示します。以下は考えられる値です。
o 0: indicates that the anomaly condition is on the protection path
o 0：異常状態が保護パス上にあることを示します
o 1: indicates that the anomaly condition is on the working path
o 1：異常状態が作業経路にあることを示します
o 2-255: for future extensions and SHALL be ignored by this version of the protocol.
o 2-255：将来の拡張のために、このバージョンのプロトコルによって無視されるものとします。
The Path field indicates which data is being transported on the protection path. Under normal conditions, the protection path (especially, in 1:1 or 1:n architecture) does not need to carry any user data traffic. If there is a failure/degrade condition on one of the working paths, then that working path's data traffic will be transported over the protection path. The following are the possible values:
パスフィールドは、保護パスでどのデータが輸送されているかを示します。通常の条件下では、保護パス（特に1：1または1：Nアーキテクチャ）では、ユーザーデータトラフィックを運ぶ必要はありません。作業経路の1つに障害/劣化状態がある場合、その作業経路のデータトラフィックは保護パスを介して輸送されます。以下は考えられる値です。
o 0: indicates that the protection path is not transporting user data traffic (in 1:n architecture) or transporting redundant user data traffic (in 1+1 architecture).
o 0：保護パスがユーザーデータトラフィック（1：Nアーキテクチャ）を輸送したり、冗長なユーザーデータトラフィック（1 1アーキテクチャ）を輸送していないことを示します。
o 1: indicates that the protection path is transmitting user traffic replacing the use of the working path.
o 1：保護パスが作業パスの使用を置き換えるユーザートラフィックを送信していることを示します。
o 2-255: for future extensions and SHALL be ignored by this version of the protocol.
o 2-255：将来の拡張のために、このバージョンのプロトコルによって無視されるものとします。
It may be necessary for future applications of the protocol to include additional information for the proper processing of the requests. For this purpose, we provide for optional additional information to be included in the PSC payload. This information MUST include a header that indicates the total length (in bytes) of the additional information.
プロトコルの将来のアプリケーションが、リクエストの適切な処理のための追加情報を含める必要がある場合があります。この目的のために、PSCペイロードに含まれるオプションの追加情報を提供します。この情報には、追加情報の全長（バイト単位）を示すヘッダーを含める必要があります。
This information includes the following fields:
この情報には、次のフィールドが含まれています。
o TLV Length: indicates the number of bytes included in the optional TLV information. For the basic PSC protocol operation described in this document, this value MUST be 0.
o TLV長：オプションのTLV情報に含まれるバイト数を示します。このドキュメントで説明されている基本的なPSCプロトコル操作の場合、この値は0でなければなりません。
o Optional TLVs: this includes any additional information formatted as TLV units. There are no TLV units defined for the basic PSC operation.
o オプションのTLV：これには、TLVユニットとしてフォーマットされた追加情報が含まれます。基本的なPSC操作のために定義されたTLVユニットはありません。
In all of the following subsections, assume a protection domain between LER-A and LER-Z, using paths W (working) and P (protection), as shown in Figure 3.
次のすべてのサブセクションで、図3に示すように、パスW（動作）とP（保護）を使用して、LER-AとLER-Zの間の保護ドメインを想定します。
+-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z|
| /| |\ |
| ?< | | >? |
| \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+
|--------Protection Domain--------|
Figure 3: Protection Domain
図3：保護ドメイン
The purpose of the PSC protocol is to allow an end point of the protection domain to notify its peer of the status of the domain that is known at the end point and coordinate the transmission of the data traffic. The current state of the end point is expressed in the values of the Request field (reflecting the local requests at that end point) and the FPath field (reflecting knowledge of a blocked path). The coordination between the end points is expressed by the value of the Path field (indicating where the user data traffic is being transmitted). Except during a protection switch, the value of the Path field should be identical for both end points at any particular time. The values of the Request and FPath fields may not be identical between the two end points. In particular it should be noted that a remote message may not cause the end point to change the Request field that is being transmitted while it does affect the Path field (see details in the following subsections).
PSCプロトコルの目的は、保護ドメインのエンドポイントが、エンドポイントで知られているドメインのステータスをピアに通知し、データトラフィックの伝送を調整できるようにすることです。エンドポイントの現在の状態は、要求フィールドの値（そのエンドポイントでのローカルリクエストを反映）とFPATHフィールド（ブロックされたパスの知識を反映する）で表されます。エンドポイント間の調整は、パスフィールドの値によって表されます（ユーザーデータトラフィックがどこで送信されているかを示します）。保護スイッチ中を除き、パスフィールドの値は、特定の時間で両方のエンドポイントで同一である必要があります。リクエストフィールドとFPATHフィールドの値は、2つのエンドポイント間で同一ではない場合があります。特に、リモートメッセージは、パスフィールドに影響を与えている間に送信されているリクエストフィールドをエンドポイントに変更しない可能性があることに注意する必要があります（以下のサブセクションの詳細を参照）。
The protocol is a single-phased protocol. "Single-phased" implies that each end point notifies its peer of a change in the operation (switching to or from the protection path) and makes the switch without waiting for acknowledgement. As a side effect of using a single-phased protocol, there will be a short period during state transitions of one-sided triggers (e.g., operator commands or unidirectional SF) when one LER may be transporting/selecting the data from one transport path while the other end point is transporting/selecting from the other transport path. This should become coordinated once the remote message is received and the far-end LER performs the protection switching operation.
プロトコルは単一のプロトコルです。「シングルフェイス」とは、各エンドポイントが操作の変更（保護パスへの切り替え）をピアに通知し、確認を待たずにスイッチを作成することを意味します。単一の段階的プロトコルを使用する副作用として、1つの輸送パスからデータを輸送/選択している場合に、片側トリガー（例：オペレーターコマンドまたは単方向SF）の状態遷移中に短い期間があります。もう1つのエンドポイントは、他の輸送パスから輸送/選択することです。これは、リモートメッセージが受信され、ファーエンドLERが保護スイッチング操作を実行すると、調整されるはずです。
The following subsections will identify the messages that will be transmitted by the end point in different scenarios. The messages are described as REQ(FP, P) -- where REQ is the value of the Request field, FP is the value of the FPath field, and P is the value of the Path field. All examples assume a protection domain between LER-A and LER-Z with a single working path and single protection path (as shown in Figure 3). Again, it should be noted that when using 1:1 protection the data traffic will be transmitted exclusively on either the protection or working path; whereas when using 1+1 protection, the traffic will be transmitted on both paths and the receiving LER should select the appropriate signal based on the state. The text will refer to this transmission/selection as "transport" of the data traffic. For 1+1 unidirectional protection, the state of the selector will only be switched in reaction to a local message. When receiving a remote message, a LER that is configured for 1+1 unidirectional protection, will transfer to the new remote state; however, it will continue to select data according to the latest known local state. When the LER transitions into the Normal state, the PSC Control Process SHALL check the persistent state of the local triggers to decide if it should further transition into a new state.
次のサブセクションでは、さまざまなシナリオでエンドポイントによって送信されるメッセージを識別します。メッセージはreq（fp、p）として記述されます。ここで、reqはリクエストフィールドの値、fpはfpathフィールドの値、pはパスフィールドの値です。すべての例は、単一の作業パスと単一の保護パスを備えたLER-AとLER-Zの間の保護ドメインを想定しています（図3を参照）。繰り返しますが、1：1の保護を使用する場合、データトラフィックは保護パスまたは作業経路のいずれかにのみ送信されることに注意してください。一方、1 1保護を使用する場合、トラフィックは両方のパスで送信され、受信LERは状態に基づいて適切な信号を選択する必要があります。テキストは、この送信/選択をデータトラフィックの「輸送」と呼びます。 1 1単方向保護の場合、セレクターの状態は、ローカルメッセージに反応してのみ切り替えられます。リモートメッセージを受信すると、1 1方向保護用に構成されたLERが新しいリモート状態に転送されます。ただし、最新の既知の地方国家に従ってデータを選択し続けます。 LERが通常の状態に移行する場合、PSC制御プロセスは、ローカルトリガーの永続的な状態をチェックして、新しい状態にさらに移行する必要があるかどうかを決定するものとします。
As noted above (in Section 3.1), the PSC Control Process accepts input from five local input sources. There is a definition of priority between the different inputs that may be triggered locally. The list of local requests in order of priority are (from highest to lowest priority):
上記のように（セクション3.1）、PSC制御プロセスは、5つのローカル入力ソースからの入力を受け入れます。ローカルでトリガーされる可能性のあるさまざまな入力の間に優先度の定義があります。優先順位の順にローカルリクエストのリストは（最高から最優先事項まで）です。
1. Clear (operator command)
1. Clear（オペレーターコマンド）
2. Lockout of protection (operator command)
2. 保護のロックアウト（オペレーターコマンド）
3. Forced Switch (operator command)
3. 強制スイッチ（オペレーターコマンド）
4. Signal Fail on protection (OAM / control-plane / server indication)
4. 保護の信号の失敗（OAM /コントロールプレーン /サーバーの表示）
5. Signal Fail on working (OAM / control-plane / server indication)
5. 信号の動作に失敗する（OAM /コントロールプレーン /サーバーの表示）
6. Signal Degrade on working (OAM / control-plane / server indication)
6. 動作時の信号分解（OAM /コントロールプレーン /サーバーの表示）
7. Clear Signal Fail/Degrade (OAM / control-plane / server indication)
7. クリア信号の失敗 /劣化（OAM /コントロールプレーン /サーバーの表示）
8. Manual Switch (operator command)
8. 手動スイッチ（オペレーターコマンド）
9. WTR Expires (WTR timer)
9. WTR有効期限が切れます（WTRタイマー）
10. No Request (default)
10. リクエストなし（デフォルト）
As was noted above, the Local Request logic SHALL always select the local input indicator with the highest priority as the current local request, i.e., only the highest priority local input will be used to affect the control logic. All local inputs with lower priority than this current local request will be ignored.
上記のように、ローカルリクエストロジックは、現在のローカルリクエストとして最優先度の高いローカル入力インジケーターを常に選択する必要があります。つまり、制御ロジックに影響を与えるために最も優先度のローカル入力のみが使用されます。この現在のローカルリクエストよりも優先度が低いすべてのローカル入力は無視されます。
The remote message from the far-end LER is assigned a priority just below the similar local input. For example, a remote Forced Switch would have a priority just below a local Forced Switch but above a local Signal Fail on protection input. As mentioned in Section 3.6.1, the state transition is determined by the higher priority input between the highest priority local input and the remote message. This also determines the classification of the state as local or remote. The following subsections detail the transition based on the current state and the higher priority of these two inputs.
ファーエンドLERからのリモートメッセージには、同様のローカル入力のすぐ下に優先度が割り当てられます。たとえば、リモートの強制スイッチは、ローカル強制スイッチのすぐ下に優先されますが、ローカル信号の上に保護入力が失敗します。セクション3.6.1で述べたように、状態遷移は、最も優先度のローカル入力とリモートメッセージの間のより高い優先度入力によって決定されます。これにより、状態の分類がローカルまたはリモートとしても決定されます。次のサブセクションでは、現在の状態とこれら2つの入力の優先度が高いことに基づいて遷移を詳述しています。
The following subsections present the operation of the different states defined in Section 3.6. For each state, we define the reaction, i.e., the new state and the message to transmit, to each possible input -- either the highest priority local input or the PSC message from the remote LER. It should be noted that the new state of the protection domain is described from the point of view of the LER that is reporting the state; therefore, the language of "the LER goes into a state" is referring to the LER reporting that the protection domain is now in this new state. If the definition states to "ignore" the message, the intention is that the protection domain SHALL remain in its current state and the LER SHALL continue transmitting (as presented in Section 4.1) the current PSC message.
次のサブセクションは、セクション3.6で定義されているさまざまな状態の動作を示しています。各状態について、反応、つまり新しい状態と、可能な各入力に送信するメッセージを定義します。保護ドメインの新しい状態は、状態を報告しているLERの観点から説明されていることに注意する必要があります。したがって、「lerが状態に入る」の言語は、保護ドメインが現在この新しい状態にあることを報告していることを指しています。定義がメッセージを「無視」すると述べた場合、保護ドメインは現在の状態にとどまり、LERが現在のPSCメッセージを送信し続ける（セクション4.1で提示されている）という意図です。
When a LER is in a remote state, i.e., state transition in reaction to a PSC message received from the far-end LER, and receives a new PSC message from the far-end LER that indicates a contradictory state, e.g., in remote Unavailable state receiving a remote FS(1,1) message, then the PSC Control logic SHALL reevaluate all inputs (both the local input and the remote message) as if the LER is in the Normal state.
LERがリモート状態にある場合、すなわち、ファーエンドLERから受信したPSCメッセージに反応して状態遷移を行い、矛盾した状態、例えばリモートで利用できない状態を示すファーエンドLERから新しいPSCメッセージを受信します。リモートFS（1,1）メッセージを受信する状態では、PSC制御ロジックは、LERが正常状態にあるかのように、すべての入力（ローカル入力とリモートメッセージの両方）を再評価するものとします。
When the protection domain has no special condition in effect, the ingress LER SHALL forward the user data along the working path, and, in the case of 1+1 protection, the Permanent Bridge will bridge the data to the protection path as well. The receiving LER SHALL read the data from the working path.
保護ドメインに特別な条件が有効でない場合、Ingress LERは作業経路に沿ってユーザーデータを転送し、1 1保護の場合、永続的なブリッジはデータを保護パスに橋渡しします。受信LERは、作業経路からデータを読み取るものとします。
When the LER transitions into the Normal state, the PSC Control Process SHALL check the persistent state of the local triggers to decide if it should further transition into a new state. If the result of this check is a transition into a new state, the LER SHALL transmit the corresponding message described in this section and SHALL use the data path corresponding to the new state. When the protection domain remains in Normal state, the end point SHALL transmit an NR(0,0) message, indicating -- Nothing to report and data traffic is being transported on the working path.
LERが通常の状態に移行する場合、PSC制御プロセスは、ローカルトリガーの永続的な状態をチェックして、新しい状態にさらに移行する必要があるかどうかを決定するものとします。このチェックの結果が新しい状態への移行である場合、LERはこのセクションで説明する対応するメッセージを送信し、新しい状態に対応するデータパスを使用するものとします。保護ドメインが正常状態のままである場合、エンドポイントはNR（0,0）メッセージを送信するものとします。
When the protection domain is in Normal state, the following transitions are relevant in reaction to a local input to the LER:
保護ドメインが正常状態にある場合、次の遷移は、lerへのローカル入力に反応して関連しています。
o A local Lockout of protection input SHALL cause the LER to go into local Unavailable state and begin transmission of an LO(0,0) message.
o 保護入力のローカルロックアウトにより、LERがローカルの利用できない状態に移動し、LO（0,0）メッセージの送信を開始するものとします。
o A local Forced Switch input SHALL cause the LER to go into local Protecting administrative state and begin transmission of an FS(1,1) message.
o ローカルの強制スイッチ入力により、LERはローカル保護管理状態に移動し、FS（1,1）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message.
o 保護パスのローカル信号障害表示により、LERがローカルの使用不能状態に移動し、SF（0,0）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the working path SHALL cause the LER to go into local Protecting failure state and begin transmission of an SF(1,1) message.
o 作業経路でのローカル信号障害表示により、LERが局所保護障害状態に移動し、SF（1,1）メッセージの送信を開始するものとします。
o A local Manual Switch input SHALL cause the LER to go into local Protecting administrative state and begin transmission of an MS(1,1) message.
o ローカルマニュアルスイッチの入力により、LERはローカル保護の管理状態に移動し、MS（1,1）メッセージの送信を開始します。
o All other local inputs SHALL be ignored.
o 他のすべてのローカル入力は無視されます。
In Normal state, remote messages would cause the following reaction from the LER:
正常状態では、リモートメッセージは次のような反応を引き起こします。
o A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state, while continuing to transmit the NR(0,0) message.
o 保護メッセージのリモートロックアウトは、NR（0,0）メッセージの送信を継続しながら、LERをリモートで利用できない状態にします。
o A remote Forced Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmitting an NR(0,1) message.
o リモートの強制スイッチメッセージは、LERをリモート保護管理状態に移動させ、NR（0,1）メッセージの送信を開始します。
o A remote Signal Fail message that indicates that the failure is on the protection path SHALL cause the LER (LER-A) to go into remote Unavailable state, while continuing to transmit the NR(0,0) message.
o 障害が保護パス上にあることを示すリモート信号の失敗メッセージは、NR（0,0）メッセージの送信を継続しながら、LER（LER-A）をリモートのない状態に移動させます。
o A remote Signal Fail message that indicates that the failure is on the working path SHALL cause the LER to go into remote Protecting failure state, and transmit an NR(0,1) message.
o 障害が作業経路にあることを示すリモート信号の失敗メッセージは、lerがリモート保護障害状態になり、NR（0,1）メッセージを送信する必要があることを示します。
o A remote Manual Switch message SHALL cause the LER to go into remote Protecting administrative state, and transmit an NR(0,1) message.
o リモートマニュアルスイッチメッセージは、LERをリモート保護管理状態に移動させ、NR（0,1）メッセージを送信する必要があります。
o All other remote messages SHALL be ignored.
o 他のすべてのリモートメッセージは無視されます。
When the protection path is unavailable -- either as a result of a Lockout operator command, or as a result of a SF detected on the protection path -- then the protection domain is in the Unavailable state. In this state, the data traffic SHALL be transported on the working path and is not protected. When the domain is in Unavailable state, the PSC messages may not get through: therefore, the protection is more dependent on the local inputs than the remote messages (that may not be received).
ロックアウトオペレーターコマンドの結果として、または保護パスで検出されたSFの結果として、保護パスが利用できない場合、保護ドメインは利用できない状態です。この状態では、データトラフィックは作業経路で輸送され、保護されていません。ドメインが利用できない状態にある場合、PSCメッセージは通過できない場合があります。したがって、保護はリモートメッセージよりもローカル入力に依存します（受信しない場合があります）。
The protection domain will exit the Unavailable state and revert to the Normal state when either the operator clears the Lockout command or the protection path recovers from the signal fail or degraded situation. Both ends will continue to send the PSC messages over the protection path, as a result of this recovery.
保護ドメインは、利用できない状態を終了し、オペレーターがロックアウトコマンドをクリアするか、信号障害または劣化した状況から回復する保護パスのいずれかをクリアすると、通常の状態に戻ります。両端は、この回復の結果として、保護パスを介してPSCメッセージを送信し続けます。
When the LER (assume LER-A) is in Unavailable state, the following transitions are relevant in reaction to a local input:
LER（LER-Aを想定）が利用できない状態にある場合、次の遷移はローカルの入力に反応して関連しています。
o A local Clear input SHALL be ignored if the LER is in remote Unavailable state. If in local Unavailable state due to a Lockout command, then the input SHALL cause the LER to go to Normal state.
o LERがリモートで利用できない状態にある場合、ローカルクリアインプットは無視されます。ロックアウトコマンドのためにローカルの利用できない状態で、入力により通常の状態になります。
o A local Lockout of protection input SHALL cause the LER to remain in local Unavailable state and transmit an LO(0,0) message to the far-end LER (LER-Z).
o 保護入力のローカルロックアウトにより、LERはローカルの使用不能状態にとどまり、LO（0,0）メッセージをファーエンドLER（LER-Z）に送信します。
o A local Clear SF of the protection path in local Unavailable state that is due to an SF on the protection path SHALL cause the LER to go to Normal state. If the LER is in remote Unavailable state but has an active local SF condition, then the local Clear SF SHALL clear the SF local condition and the LER SHALL remain in remote Unavailable state and begin transmitting NR(0,0) messages. In all other cases, the local Clear SF SHALL be ignored.
o 保護パス上のSFが原因であるローカル利用不能状態の保護パスのローカルクリアSFは、通常の状態に移動するものとします。LERがリモートで利用できない状態にあるが、アクティブなローカルSF条件がある場合、局所的なクリアSFはSFの局所状態をクリアし、LERはリモート利用不能状態のままで、NR（0,0）メッセージの送信を開始するものとします。他のすべてのケースでは、ローカルクリアSFは無視されます。
o A local Forced Switch SHALL be ignored by the PSC Control logic when in Unavailable state as a result of a (local or remote) Lockout of protection. If in Unavailable state due to an SF on protection, then the FS SHALL cause the LER to go into local Protecting administrative state and begin transmitting an FS(1,1) message. It should be noted that due to the unavailability of the protection path (i.e., due to the SF condition) that this FS may not be received by the far-end until the SF condition is cleared.
o 保護の（ローカルまたはリモートの）ロックアウトの結果として、利用できない状態にある場合、ローカル強制スイッチは、PSC制御ロジックによって無視されます。保護に関するSFのために利用できない状態にある場合、FSはLERをローカル保護管理状態に移動させ、FS（1,1）メッセージの送信を開始するものとします。保護パスが利用できないため（つまり、SF条件のため）、このFSはSF条件がクリアされるまで遠端によって受信されない可能性があることに注意する必要があります。
o A local Signal Fail on the protection path input when in local Unavailable state (by implication, this is due to a local SF on protection) SHALL cause the LER to remain in local Unavailable state and transmit an SF(0,0) message.
o ローカルのない状態では、ローカル信号が保護パス入力で失敗します（これは、これは保護に関するローカルSFによるものです）。
o A local Signal Fail on the working path input when in remote Unavailable state SHALL cause the LER to remain in remote Unavailable state and transmit an SF(1,0) message.
o リモートで利用できない状態で、LERがリモートの使用不能状態にとどまり、SF（1,0）メッセージを送信する場合、ローカル信号は作動パス入力で失敗します。
o All other local inputs SHALL be ignored.
o 他のすべてのローカル入力は無視されます。
If remote messages are being received over the protection path, then they would have the following effect:
保護パスでリモートメッセージが受信されている場合、次の効果があります。
o A remote Lockout of protection message SHALL cause the LER to remain in Unavailable state (note that if the LER was previously in local Unavailable state due to a Signal Fail on the protection path, then it will now be in remote Unavailable state) and continue transmission of the current message (either NR(0,0) or LO(0,0) or SF(0,0)).
o 保護メッセージのリモートロックアウトにより、LERが利用できない状態のままになります（保護パスの信号が失敗したためにLERが以前にローカル利用できない状態であった場合、現在はリモート利用不能状態になります）。現在のメッセージ（NR（0,0）またはLO（0,0）またはSF（0,0）のいずれか）。
o A remote Forced Switch message SHALL be ignored by the PSC Control logic when in Unavailable state as a result of a (local or remote) Lockout of protection. If in Unavailable state due to a local or remote SF on protection, then the FS SHALL cause the LER to go into remote Protecting administrative state; if in Unavailable state due to local SF, begin transmitting an SF(0,1) message.
o リモート強制スイッチメッセージは、保護の（ローカルまたはリモートの）ロックアウトの結果として、利用できない状態にある場合、PSC制御ロジックによって無視されます。保護に関するローカルまたはリモートSFのために利用できない状態にある場合、FSはLERをリモート保護管理状態に入れるようにしなければならない。ローカルSFのために利用できない状態の場合、SF（0,1）メッセージの送信を開始します。
o A remote Signal Fail message that indicates that the failure is on the protection path SHALL cause the LER to remain in Unavailable state and continue transmission of the current message (either NR(0,0) or SF(0,0) or LO(0,0)).
o 障害が保護パス上にあることを示すリモート信号の失敗メッセージは、LERを利用できない状態に留まらせ、現在のメッセージ（NR（0,0）またはSF（0,0）またはLO（0）の送信を継続するものとします。、0））。
o A remote No Request, when the LER is in remote Unavailable state and there is no active local Signal Fail SHALL cause the LER to go into Normal state and continue transmission of the current message. If there is a local Signal Fail on the protection path, the LER SHALL remain in local Unavailable state and transmit an SF(0,0) message. If there is a local Signal Fail on the working path, the LER SHALL go into local Protecting Failure state and transmit an SF(1,1) message. When in local Unavailable state, the remote message SHALL be ignored.
o リモートなしの要求は、LERがリモートの利用できない状態にあり、アクティブなローカル信号障害がない場合、LERが通常の状態になり、現在のメッセージの送信を継続する必要があります。保護パスにローカル信号が故障している場合、LERはローカル利用不能状態のままで、SF（0,0）メッセージを送信するものとします。局所信号が作業経路に失敗した場合、LERは局所保護障害状態に移動し、SF（1,1）メッセージを送信するものとします。ローカルで利用できない状態では、リモートメッセージは無視されます。
o All other remote messages SHALL be ignored.
o 他のすべてのリモートメッセージは無視されます。
In the Protecting administrative state, the user data traffic SHALL be transported on the protection path, while the working path is blocked due to an operator command, i.e., Forced Switch or Manual Switch. The difference between a local FS and local MS affects what local indicators may be received -- the Local Request logic will block any local SF when under the influence of a local FS, whereas the SF would override a local MS. In general, an MS will be canceled in case of either a local or remote SF or LO condition.
管理状態の保護では、ユーザーデータトラフィックは保護パスで輸送されますが、オペレーターコマンド、つまり強制スイッチまたは手動スイッチのために作業経路がブロックされます。ローカルFSとローカルMSの違いは、ローカルインジケーターを受信する可能性のあるものに影響します。ローカルリクエストロジックは、ローカルFSの影響下にある場合にローカルSFをブロックしますが、SFはローカルMSをオーバーライドします。一般に、ローカルまたはリモートのSFまたはLO条件のいずれかの場合、MSはキャンセルされます。
The following describe the reaction to local input:
以下は、ローカル入力に対する反応を説明しています。
o A local Clear SHALL be ignored if in remote Protecting administrative state. If in local Protecting administrative state, then this input SHALL cause the LER to go into Normal state.
o リモート保護状態の場合、ローカルクリアは無視されます。ローカル保護状態で行政状態を保護する場合、この入力により、LERが通常の状態になります。
o A local Lockout of protection input SHALL cause the LER to go into local Unavailable state and begin transmission of an LO(0,0) message.
o 保護入力のローカルロックアウトにより、LERがローカルの利用できない状態に移動し、LO（0,0）メッセージの送信を開始するものとします。
o A local Forced Switch input SHALL cause the LER to remain in local Protecting administrative state and transmit an FS(1,1) message.
o ローカルの強制スイッチ入力により、LERはローカル保護の管理状態にとどまり、FS（1,1）メッセージを送信します。
o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message, if the current state is due to a (local or remote) Manual Switch operator command. If the LER is in (local or remote) Protecting administrative state due to an FS situation, then the SF on protection SHALL be ignored.
o 保護パスのローカル信号障害表示により、現在の状態が（ローカルまたはリモートの）マニュアルスイッチオペレーターコマンドが原因である場合、LERがローカル利用不能状態になり、SF（0,0）メッセージの送信を開始します。FSの状況により、LERが管理状態を保護する（ローカルまたはリモート）場合、保護に関するSFは無視されます。
o A local Signal Fail indication on the working path SHALL cause the LER to go into local Protecting failure state and begin transmitting an SF(1,1) message, if the current state is due to a (local or remote) Manual Switch operator command. If the LER is in remote Protecting administrative state due to a remote Forced Switch command, then this local indication SHALL cause the LER to remain in remote Protecting administrative state and transmit an SF(1,1) message. If the LER is in local Protecting administrative state due to a local Forced Switch command, then this indication SHALL be ignored (i.e., the indication should have been blocked by the Local Request logic).
o 現在の状態が（ローカルまたはリモートの）マニュアルスイッチオペレーターコマンドが原因である場合、局所信号障害の表示により、局所的な信号が故障状態になり、SF（1,1）メッセージの送信を開始し、SF（1,1）メッセージの送信を開始します。LERがリモートの強制スイッチコマンドのためにリモート保護管理状態にある場合、このローカルな適応症により、LERはリモート保護の管理状態を保護し、SF（1,1）メッセージを送信します。ローカル強制スイッチコマンドのためにLERが行政状態を保護している場合、この兆候は無視されます（つまり、指示はローカルリクエストロジックによってブロックされるべきでした）。
o A local Clear SF SHALL clear any local SF condition that may exist. If in remote Protecting administrative state, the LER SHALL stop transmitting the SF(x,1) message and begin transmitting an NR(0,1) message.
o ローカルクリアSFは、存在する可能性のあるローカルSF条件をクリアするものとします。リモート保護の管理状態で、LERはSF（x、1）メッセージの送信を停止し、NR（0,1）メッセージの送信を開始するものとします。
o A local Manual Switch input SHALL be ignored if in remote Protecting administrative state due to a remote Forced Switch command. If the current state is due to a (local or remote) Manual Switch operator command, it SHALL cause the LER to remain in local Protecting administrative state and transmit an MS(1,1) message.
o リモートの強制スイッチコマンドのために管理状態をリモート保護する場合、ローカルマニュアルスイッチの入力は無視されます。現在の状態が（ローカルまたはリモートの）マニュアルスイッチオペレーターコマンドが原因である場合、LERはローカル保護の管理状態に留まり、MS（1,1）メッセージを送信します。
o All other local inputs SHALL be ignored.
o 他のすべてのローカル入力は無視されます。
While in Protecting administrative state the LER may receive and react as follows to remote PSC messages:
管理状態を保護している間、LERはリモートPSCメッセージに次のように受信して反応する場合があります。
o A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state and begin transmitting an NR(0,0) message. It should be noted that this automatically cancels the current Forced Switch or Manual Switch command and data traffic is reverted to the working path.
o 保護メッセージのリモートロックアウトにより、LERがリモートのない状態になり、NR（0,0）メッセージの送信を開始します。これにより、現在の強制スイッチまたは手動スイッチコマンドが自動的にキャンセルされ、データトラフィックが作業パスに戻されることに注意してください。
o A remote Forced Switch message SHALL be ignored by the PSC Process logic if there is an active local Forced Switch operator command. If the Protecting administrative state is due to a remote Forced Switch message, then the LER SHALL remain in remote Protecting administrative state and continue transmitting the last message. If the Protecting administrative state is due to either a local or
o アクティブなローカル強制スイッチオペレーターコマンドがある場合、リモートの強制スイッチメッセージは、PSCプロセスロジックによって無視されます。管理状態を保護する場合、リモートの強制スイッチメッセージが原因である場合、LERは管理状態を保護するリモートに留まり、最後のメッセージの送信を続けます。保護行政状態がローカルまたは
remote Manual Switch, then the LER SHALL remain in remote Protecting administrative state (updating the state information with the proper relevant information) and begin transmitting an NR(0,1) message.
リモートマニュアルスイッチ、その後、LERはリモート保護状態（適切な関連情報を使用して状態情報を更新する）を保護し、NR（0,1）メッセージの送信を開始するものとします。
o A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into remote Unavailable state and begin transmitting an NR(0,0) message, if the Protecting administrative state is due to a Manual Switch command. It should be noted that this automatically cancels the current Manual Switch command and data traffic is reverted to the working path.
o 保護パスの障害を示すリモート信号の失敗メッセージは、保護状態が手動スイッチコマンドによるものである場合、LERをリモートのない状態にし、NR（0,0）メッセージの送信を開始するものとします。これにより、現在のマニュアルスイッチコマンドが自動的にキャンセルされ、データトラフィックが作業経路に戻されることに注意してください。
o A remote Signal Fail message indicating a failure on the working path SHALL be ignored if there is an active local Forced Switch command. If the Protecting state is due to a local or remote Manual Switch, then the LER SHALL go to remote Protecting failure state and begin transmitting an NR(0,1) message.
o アクティブなローカル強制スイッチコマンドがある場合、作業パスの障害が無視されることを示すリモート信号障害メッセージ。保護状態がローカルまたはリモートのマニュアルスイッチが原因である場合、LERはリモート保護障害状態に移動し、NR（0,1）メッセージの送信を開始します。
o A remote Manual Switch message SHALL be ignored by the PSC Control logic if in Protecting administrative state due to a local or remote Forced Switch. If in Protecting administrative state due to a remote Manual Switch, then the LER SHALL remain in remote Protecting administrative state and continue transmitting the current message. If in local Protecting administrative state due to an active Manual Switch, then the LER SHALL remain in local Protecting administrative state and continue transmission of the MS(1,1) message.
o ローカルまたはリモートの強制スイッチのために管理状態を保護する場合、リモートマニュアルスイッチメッセージは、PSC制御ロジックによって無視されます。リモートマニュアルスイッチのために管理状態を保護する場合、LERは管理状態を保護するリモートに留まり、現在のメッセージの送信を継続するものとします。アクティブなマニュアルスイッチのためにローカル保護管理状態で行政状態を保護する場合、LERはローカル保護状態を保護し、MS（1,1）メッセージの送信を継続するものとします。
o A remote DNR(0,1) message SHALL be ignored if in local Protecting administrative state. If in remote Protecting administrative state, then the LER SHALL go to Do-not-Revert state and continue transmitting the current message.
o リモートDNR（0,1）メッセージは、ローカル保護状態の場合、無視されます。リモート保護状態で行政状態を保護する場合、LERはdo-not-revert状態に移動し、現在のメッセージの送信を続けます。
o A remote NR(0,0) message SHALL be ignored if in local Protecting administrative state. If in remote Protecting administrative state and there is no active local Signal Fail indication, then the LER SHALL go to Normal state and begin transmitting an NR(0,0) message. If there is a local Signal Fail on the working path, the LER SHALL go to local Protecting failure state and begin transmitting an SF(1,1) message.
o リモートNR（0,0）メッセージは、ローカル保護状態の場合、無視されます。リモート保護管理状態で、アクティブな局所信号障害表示がない場合、LERは通常の状態に移動し、NR（0,0）メッセージの送信を開始します。局所信号が作業経路に失敗した場合、LERは局所保護障害状態に移動し、SF（1,1）メッセージの送信を開始します。
o All other remote messages SHALL be ignored.
o 他のすべてのリモートメッセージは無視されます。
When the protection mechanism has been triggered and the protection domain has performed a protection switch, the domain is in the Protecting failure state. In this state, the normal data traffic
保護メカニズムがトリガーされ、保護ドメインが保護スイッチを実行すると、ドメインは保護障害状態にあります。この状態では、通常のデータトラフィック
SHALL be transported on the protection path. When an LER is in this state, it implies that there either was a local SF condition or it received a remote SF PSC message. The SF condition or message indicated that the failure is on the working path.
保護経路に輸送されます。この状態にある場合、それはローカルSF状態があるか、リモートSF PSCメッセージを受け取ったことを意味します。SF条件またはメッセージは、障害が作業経路にあることを示しました。
This state may be overridden by the Unavailable state triggers, i.e., Lockout of protection or SF on the protection path, or by issuing an FS operator command. This state will be cleared when the SF condition is cleared. In order to prevent flapping due to an intermittent fault, the LER SHOULD employ a Wait-to-Restore timer to delay return to Normal state until the network has stabilized (see Section 3.5).
この状態は、利用できない状態トリガー、つまり保護パス上の保護またはSFのロックアウト、またはFSオペレーターコマンドの発行によってオーバーライドされる場合があります。この状態は、SF条件がクリアされるとクリアされます。断続的な障害による羽ばたきを防ぐために、LERは、ネットワークが安定するまで通常の状態に戻ることを遅らせるために待機対策タイマーを使用する必要があります（セクション3.5を参照）。
The following describe the reaction to local input:
以下は、ローカル入力に対する反応を説明しています。
o A local Clear SF SHALL be ignored if in remote Protecting failure state. If in local Protecting failure state and the LER is configured for revertive behavior, then this input SHALL cause the LER to go into Wait-to-Restore state, start the WTR timer, and begin transmitting a WTR(0,1) message. If in local Protecting failure state and the LER is configured for non-revertive behavior, then this input SHALL cause the LER to go into Do-not-Revert state and begin transmitting a DNR(0,1) message.
o リモート保護障害状態の場合、ローカルクリアSFは無視されます。局所保護障害状態とlERが戻る動作のために構成されている場合、この入力により、LERが待機状態になり、WTRタイマーを開始し、WTR（0,1）メッセージの送信を開始します。局所保護障害状態と非反転挙動のためにLERが構成されている場合、この入力により、LERがdo-revert状態になり、DNR（0,1）メッセージの送信を開始します。
o A local Lockout of protection input SHALL cause the LER to go into Unavailable state and begin transmission of an LO(0,0) message.
o 保護入力のローカルロックアウトにより、LERが利用できない状態になり、LO（0,0）メッセージの送信を開始するものとします。
o A local Forced Switch input SHALL cause the LER to go into Protecting administrative state and begin transmission of an FS(1,1) message.
o ローカルな強制スイッチ入力により、LERが管理状態を保護し、FS（1,1）メッセージの送信を開始するようにします。
o A local Signal Fail indication on the protection path SHALL cause the LER to go into Unavailable state and begin transmission of an SF(0,0) message.
o 保護パスのローカル信号障害表示により、LERが利用できない状態になり、SF（0,0）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the working path SHALL cause the LER to remain in local Protecting failure state and transmit an SF(1,1) message.
o 作業経路でのローカル信号障害の表示により、LERは局所保護障害状態に留まり、SF（1,1）メッセージを送信します。
o All other local inputs SHALL be ignored.
o 他のすべてのローカル入力は無視されます。
While in Protecting failure state, the LER may receive and react as follows to remote PSC messages:
障害状態を保護することで、LERはリモートPSCメッセージに次のように受信して反応する場合があります。
o A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state, and if in local Protecting failure state, then the LER SHALL transmit an SF(1,0) message; otherwise,
o 保護メッセージのリモートロックアウトにより、LERがリモートの使用不能状態になり、局所保護障害状態の場合、LERはSF（1,0）メッセージを送信するものとします。それ以外は、
it SHALL transmit an NR(0,0) message. It should be noted that this may cause loss of user data since the working path is still in a failure condition.
NR（0,0）メッセージを送信します。作業経路はまだ故障状態にあるため、これがユーザーデータの損失を引き起こす可能性があることに注意する必要があります。
o A remote Forced Switch message SHALL cause the LER go into remote Protecting administrative state, and if in local Protecting failure state, the LER SHALL transmit the SF(1,1) message; otherwise, it SHALL transmit NR(0,1).
o リモートの強制スイッチメッセージは、LERがリモート保護管理状態に移動し、局所保護障害状態でsf（1,1）メッセージを送信する場合、それ以外の場合、NR（0,1）を送信します。
o A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into remote Unavailable state, and if in local Protecting failure state, then the LER SHALL transmit an SF(1,0) message; otherwise, it SHALL transmit an NR(0,0) message. It should be noted that this may cause loss of user data since the working path is still in a failure condition.
o 保護パスの障害を示すリモート信号の失敗メッセージは、LERをリモートの使用不能状態にし、局所保護障害状態にある場合、LERはSF（1,0）メッセージを送信するものとします。それ以外の場合、NR（0,0）メッセージを送信します。作業経路はまだ故障状態にあるため、これがユーザーデータの損失を引き起こす可能性があることに注意する必要があります。
o If in remote Protecting failure state, a remote Wait-to-Restore message SHALL cause the LER to go into remote Wait-to-Restore state and continue transmission of the current message.
o リモート保護障害状態の場合、リモートの待機対策メッセージは、LERをリモートの待機状態にし、現在のメッセージの送信を継続するようにします。
o If in remote Protecting failure state, a remote Do-not-Revert message SHALL cause the LER to go into remote Do-not-Revert state and continue transmission of the current message.
o リモート保護障害状態で、リモートドゥノットリバートメッセージは、LERをリモートドノットリバート状態に移動させ、現在のメッセージの送信を継続するものとします。
o If in remote Protecting failure state, a remote NR(0,0) SHALL cause the LER to go to Normal state.
o リモート保護障害状態で、リモートNR（0,0）が通常の状態に移動するようにします。
o All other remote messages SHALL be ignored.
o 他のすべてのリモートメッセージは無視されます。
When recovering from a failure condition on the working path, the Wait-to-Restore state is used by the PSC protocol to delay reverting to the Normal state, for the period of the WTR timer to allow the recovering failure to stabilize. While in the Wait-to-Restore state, the data traffic SHALL continue to be transported on the protection path. The natural transition from the Wait-to-Restore state to Normal state will occur when the WTR timer expires.
作業経路の故障条件から回復する場合、WAT-RESTORE状態はPSCプロトコルによって使用され、通常の状態への戻りを遅らせます。待機対象の状態では、データトラフィックは引き続き保護パスで輸送されます。WTRタイマーが期限切れになったときに、待機状態から正常状態への自然な移行が発生します。
When in Wait-to-Restore state, the following describe the reaction to local inputs:
待機状態の状態で、以下はローカル入力に対する反応を説明しています。
o A local Lockout of protection command SHALL send the Stop command to the WTR timer, go into local Unavailable state, and begin transmitting an LO(0,0) message.
o 保護コマンドのローカルロックアウトは、STOPコマンドをWTRタイマーに送信し、ローカルの利用できない状態に移動し、LO（0,0）メッセージの送信を開始するものとします。
o A local Forced Switch command SHALL send the Stop command to the WTR timer, go into local Protecting administrative state, and begin transmission of an FS(1,1) message.
o ローカル強制スイッチコマンドは、停止コマンドをWTRタイマーに送信し、ローカル保護管理状態に移動し、FS（1,1）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the protection path SHALL send the Stop command to the WTR timer, go into local Unavailable state, and begin transmission of an SF(0,0) message.
o 保護パスのローカル信号障害表示は、停止コマンドをWTRタイマーに送信し、ローカルのない状態に移動し、SF（0,0）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the working path SHALL send the Stop command to the WTR timer, go into local Protecting failure state, and begin transmission of an SF(1,1) message.
o 作業パスでのローカル信号の失敗表示は、停止コマンドをWTRタイマーに送信し、ローカル保護障害状態に移動し、SF（1,1）メッセージの送信を開始するものとします。
o A local Manual Switch input SHALL send the Stop command to the WTR timer, go into local Protecting administrative state, and begin transmission of an MS(1,1) message.
o ローカルマニュアルスイッチ入力は、停止コマンドをWTRタイマーに送信し、ローカル保護管理状態に移動し、MS（1,1）メッセージの送信を開始するものとします。
o A local WTR Expires input SHALL cause the LER to remain in Wait-to-Restore state, and begin transmitting an NR(0,1) message.
o ローカルWTRの有効期限は、LERを待機状態にとどめ、NR（0,1）メッセージの送信を開始します。
o All other local inputs SHALL be ignored.
o 他のすべてのローカル入力は無視されます。
When in Wait-to-Restore state, the following describe the reaction to remote messages:
待機状態にある場合、次のことはリモートメッセージに対する反応を説明しています。
o A remote Lockout of protection message SHALL send the Stop command to the WTR timer, go into remote Unavailable state, and begin transmitting an NR(0,0) message.
o 保護メッセージのリモートロックアウトは、STOPコマンドをWTRタイマーに送信し、リモートのない状態に移動し、NR（0,0）メッセージの送信を開始します。
o A remote Forced Switch message SHALL send the Stop command to the WTR timer, go into remote Protecting administrative state, and begin transmission of an NR(0,1) message.
o リモート強制スイッチメッセージは、停止コマンドをWTRタイマーに送信し、リモート保護管理状態に移動し、NR（0,1）メッセージの送信を開始するものとします。
o A remote Signal Fail message for the protection path SHALL send the Stop command to the WTR timer, go into remote Unavailable state, and begin transmission of an NR(0,0) message.
o 保護パスのリモート信号失敗メッセージは、停止コマンドをWTRタイマーに送信し、リモートのない状態に移動し、NR（0,0）メッセージの送信を開始するものとします。
o A remote Signal Fail message for the working path SHALL send the Stop command to the WTR timer, go into remote Protecting failure state, and begin transmission of an NR(0,1) message.
o 動作パスのリモート信号失敗メッセージは、停止コマンドをWTRタイマーに送信し、リモート保護障害状態に移動し、NR（0,1）メッセージの送信を開始するものとします。
o A remote Manual Switch message SHALL send the Stop command to the WTR timer, go into remote Protecting administrative state, and begin transmission of an NR(0,1) message.
o リモートマニュアルスイッチメッセージは、STOPコマンドをWTRタイマーに送信し、リモート保護管理状態に移動し、NR（0,1）メッセージの送信を開始します。
o If the WTR timer is running, then a remote NR message SHALL be ignored. If the WTR timer is stopped, then a remote NR message SHALL cause the LER to go into Normal state.
o WTRタイマーが実行されている場合、リモートNRメッセージは無視されます。WTRタイマーが停止した場合、リモートNRメッセージにより、LERが正常状態になります。
o All other remote messages SHALL be ignored.
o 他のすべてのリモートメッセージは無視されます。
Do-not-Revert state is a continuation of the Protecting failure state when the protection domain is configured for non-revertive behavior. While in Do-not-Revert state, data traffic SHALL continue to be transported on the protection path until the administrator sends a command to revert to Normal state. It should be noted that there is a fundamental difference between this state and Normal -- whereas Forced Switch in Normal state actually causes a switch in the transport path used, in Do-not-Revert state, the Forced Switch just switches the state (to Protecting administrative state) but the traffic would continue to be transported on the protection path! To revert back to Normal state, the administrator SHALL issue a Lockout of protection command followed by a Clear command.
do-not-revert状態は、非反転挙動のために保護ドメインが構成されている場合の保護障害状態の継続です。do-not-revert状態では、管理者がコマンドを送信して通常の状態に戻るまで、データトラフィックは引き続き保護パスで輸送されます。この状態と通常の間には根本的な違いがあることに注意する必要がありますが、通常の状態の強制スイッチは、実際に使用される輸送パスにスイッチを引き起こします。管理状態を保護します）しかし、トラフィックは引き続き保護パスで輸送されます！通常の状態に戻すために、管理者は保護コマンドのロックアウトに続いて明確なコマンドを発行するものとします。
When in Do-not-Revert state, the following describe the reaction to local input:
do-not-revert状態で、以下はローカル入力に対する反応を説明します。
o A local Lockout of protection command SHALL cause the LER to go into local Unavailable state and begin transmitting an LO(0,0) message.
o 保護コマンドのローカルロックアウトにより、LERがローカルの利用できない状態に移動し、LO（0,0）メッセージの送信を開始するものとします。
o A local Forced Switch command SHALL cause the LER to go into local Protecting administrative state and begin transmission of an FS(1,1) message.
o ローカル強制スイッチコマンドは、LERをローカル保護管理状態に移動させ、FS（1,1）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message.
o 保護パスのローカル信号障害表示により、LERがローカルの使用不能状態に移動し、SF（0,0）メッセージの送信を開始するものとします。
o A local Signal Fail indication on the working path SHALL cause the LER to go into local Protecting failure state and begin transmission of an SF(1,1) message.
o 作業経路でのローカル信号障害表示により、LERが局所保護障害状態に移動し、SF（1,1）メッセージの送信を開始するものとします。
o A local Manual Switch input SHALL cause the LER to go into local Protecting administrative state and begin transmission of an MS(1,1) message.
o ローカルマニュアルスイッチの入力により、LERはローカル保護の管理状態に移動し、MS（1,1）メッセージの送信を開始します。
o All other local inputs SHALL be ignored.
o 他のすべてのローカル入力は無視されます。
When in Do-not-Revert state, the following describe the reaction to remote messages:
do-not-revert状態で、次のことはリモートメッセージに対する反応を説明します。
o A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state and begin transmitting an NR(0,0) message.
o 保護メッセージのリモートロックアウトにより、LERがリモートのない状態になり、NR（0,0）メッセージの送信を開始します。
o A remote Forced Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmission of an NR(0,1) message.
o リモートの強制スイッチメッセージは、LERをリモート保護管理状態に移動させ、NR（0,1）メッセージの送信を開始します。
o A remote Signal Fail message for the protection path SHALL cause the LER to go into remote Unavailable state and begin transmission of an NR(0,0) message.
o 保護パスのリモート信号障害メッセージは、LERをリモートのない状態に移動させ、NR（0,0）メッセージの送信を開始するものとします。
o A remote Signal Fail message for the working path SHALL cause the LER to go into remote Protecting failure state and begin transmission of an NR(0,1) message.
o 動作パスのリモート信号フェイルメッセージは、LERをリモート保護障害状態に移動させ、NR（0,1）メッセージの送信を開始するものとします。
o A remote Manual Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmission of an NR(0,1) message.
o リモートマニュアルスイッチメッセージは、LERをリモート保護管理状態に移動させ、NR（0,1）メッセージの送信を開始する必要があります。
o All other remote messages SHALL be ignored.
o 他のすべてのリモートメッセージは無視されます。
In the "Pseudowire Name Spaces (PWE3)" registry, IANA maintains the "Pseudowire Associated Channel Types" registry.
「擬似ワイヤ名スペース（PWE3）」レジストリでは、IANAは「擬似されたチャネルタイプ」レジストリを維持しています。
IANA has assigned a new code point from this registry. The code point has been assigned from the code point space that requires "IETF Review" as follows:
IANAは、このレジストリから新しいコードポイントを割り当てました。コードポイントは、次のように「IETFレビュー」を必要とするコードポイントスペースから割り当てられています。
Registry:
レジストリ：
Value Description TLV Follows Reference
------ ----------------------- ----------- ---------------
0x0024 Protection State no [this document]
Coordination Protocol -
Channel Type (PSC-CT)
IANA has created and maintains a new sub-registry within the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry called the "MPLS PSC Request Registry". All code points within this registry shall be allocated according to the "Standards Action" procedure as specified in [RFC5226].
IANAは、「MPLS PSCリクエストレジストリ」と呼ばれる「マルチプロトコルラベルスイッチング（MPLS）操作、管理、および管理（OAM）パラメーター」レジストリ内で新しいサブレジストリを作成および維持しています。このレジストリ内のすべてのコードポイントは、[RFC5226]で指定されている「標準訴訟」手順に従って割り当てられます。
The PSC Request Field is 4 bits, and the values have been allocated as follows:
PSCリクエストフィールドは4ビットで、値は次のように割り当てられています。
Value Description Reference
----- --------------------- ---------------
0 No Request [this document]
1 Do-not-Revert [this document]
2 - 3 Unassigned
4 Wait-to-Restore [this document]
5 Manual Switch [this document]
6 Unassigned
7 Signal Degrade [this document]
8 - 9 Unassigned
10 Signal Fail [this document]
11 Unassigned
12 Forced Switch [this document]
13 Unassigned
14 Lockout of protection [this document]
15 Unassigned
The IANA has created and maintains a new sub-registry within the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry called the "MPLS PSC TLV Registry". All code points within this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226].
IANAは、「MPLS PSC TLVレジストリ」と呼ばれる「マルチプロトコルラベルスイッチング（MPLS）操作、管理、および管理（OAM）パラメーター」レジストリ内で新しいサブレジストリを作成および維持しています。このレジストリ内のすべてのコードポイントは、[RFC5226]で指定されている「IETFレビュー」手順に従って割り当てられます。
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of the security model of MPLS. MPLS networks make the assumption that it is very hard to inject traffic into a network and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see [RFC5920].
MPLS-TPはMPLSのサブセットであるため、MPLSのセキュリティモデルの多くの側面に基づいています。MPLSネットワークは、ネットワークにトラフィックを注入することが非常に難しく、ネットワークの外側にトラフィックを向けることも同様に難しいと仮定しています。コントロールプレーンプロトコルは、ホップバイホップセキュリティを利用し、エンドツーエンドのコントロールプレーンセキュリティが使用されないように「トラストチェーン」モデルを想定しています。MPLSセキュリティの一般的な側面の詳細については、[RFC5920]を参照してください。
This document describes a protocol carried in the G-ACh [RFC5586], and so is dependent on the security of the G-ACh, itself. The G-ACh is a generalization of the Associated Channel defined in [RFC4385]. Thus, this document relies heavily on the security mechanisms provided for the Associated Channel and described in those two documents.
このドキュメントでは、G-ach [RFC5586]に掲載されたプロトコルについて説明しているため、G-ach自体のセキュリティに依存しています。G-achは、[RFC4385]で定義された関連チャネルの一般化です。したがって、このドキュメントは、関連するチャネルに提供され、これら2つのドキュメントで説明されているセキュリティメカニズムに大きく依存しています。
A specific concern for the G-ACh is that is can be used to provide a covert channel. This problem is wider than the scope of this document and does not need to be addressed here, but it should be noted that the channel provides end-to-end connectivity and SHOULD
G-achの特定の懸念は、秘密チャネルを提供するために使用できることです。この問題はこのドキュメントの範囲よりも広く、ここで対処する必要はありませんが、チャネルがエンドツーエンドの接続を提供していることに注意する必要があります。
NOT be policed by transit nodes. Thus, there is no simple way of preventing any traffic being carried between in the G-ACh consenting nodes.
トランジットノードによってポリシングされていません。したがって、G-achの同意ノードの間にトラフィックが運ばれるのを防ぐ簡単な方法はありません。
A good discussion of the data-plane security of an associated channel may be found in [RFC5085]. That document also describes some mitigation techniques.
関連するチャネルのデータ平面セキュリティの良い議論は、[RFC5085]に記載されている場合があります。そのドキュメントでは、いくつかの緩和手法についても説明しています。
It should be noted that the G-ACh is essentially connection oriented so injection or modification of control messages specified in this document require the subversion of a transit node. Such subversion is generally considered hard in MPLS networks and impossible to protect against at the protocol level. Management level techniques are more appropriate.
G-achは本質的に接続指向であるため、このドキュメントで指定された制御メッセージの注入または修正には、トランジットノードの転換が必要であることに注意する必要があります。このような転覆は、一般にMPLSネットワークでは困難であると考えられており、プロトコルレベルで保護することは不可能です。管理レベルの手法がより適切です。
However, a new concern for this document is the accidental corruption of messages (through faulty implementations or random corruption). The main concern is around the Request, FPath, and Path fields as a change to these fields would change the behavior of the peer end point. Although this document does not define a way to avoid a change in network behavior upon receipt of a message indicating a change in protection status, the transition between states will converge on a known and stable behavior in the face of messages that do not match reality.
ただし、このドキュメントの新しい懸念は、メッセージの偶発的な破損です（誤った実装またはランダム破損による）。主な関心事は、これらのフィールドの変更がピアエンドポイントの動作を変更するため、リクエスト、FPATH、およびパスフィールドに関するものです。このドキュメントは、保護ステータスの変化を示すメッセージの受信時にネットワークの動作の変更を回避する方法を定義していませんが、州間の遷移は、現実と一致しないメッセージに直面して既知の安定した動作に収束します。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in the IETF, and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of the MPLS Transport Profile.
著者は、MPLSトランスポートプロファイルの定義と仕様に関与するチームのすべてのメンバー（IETFの共同作業チーム、IETFのMPLS相互運用性デザインチーム、およびITU-TのT-MPLSアドホックグループ）に感謝したいと思います。。
Hao Long Huawei Technologies Co., Ltd. F3 Building, Huawei Industrial Park Bantian, Shenzhen, China
Hao Long Huawei Technologies Co.、Ltd。F3 Building、Huawei Industrial Park Bantian、Shenzhen、China
EMail: longhao@huawei.com
Davide Chiara Ericsson Via Calda 5, 16152 Genova Italy
Davide Chiara Ericsson経由でCalda 5、16152 Genova Italy
EMail: davide.chiara@ericsson.com
Dan Frost Cisco Systems
ダンフロストシスコシステム
EMail: danfrost@cisco.com
Francesco Fondelli Ericsson via Moruzzi 1 56100, Pisa Italy
フランチェスコ・フォンデッリ・エリクソンはモルッツィ1 56100、ピサ・イタリア
EMail: francesco.fondelli@ericsson.com
[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月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Vigoureux、M。、およびS. Bryant、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[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月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Rekhter、Y。、およびD. Papadimitriou、「RSVP-TE拡張は、エンドツーエンドの一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする」、2007年5月、RFC 4872。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[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、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤーエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、Bryant、S.、Frost、D.、Levrau、L。、およびL. Berger、「輸送ネットワークにおけるMPLのフレームワーク」、RFC 5921、2010年7月。
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372] Sprecher、N.、ed。and A. Farrel、ed。、「MPLS輸送プロファイル（MPLS-TP）Survivability Framework」、RFC 6372、2011年9月。
The PSC state machine is described in Section 4.3.3. This appendix provides the same information but in tabular format. In the event of a mismatch between these tables and the text in Section 4.3.3, the text is authoritative. Note that this appendix is intended to be a functional description, not an implementation specification.
PSC状態マシンについては、セクション4.3.3で説明しています。この付録は同じ情報を提供しますが、表形式です。これらのテーブルとセクション4.3.3のテキストの間に不一致がある場合、テキストは権威があります。この付録は、実装仕様ではなく、機能的な説明であることを目的としていることに注意してください。
For the sake of clarity of the table, the six states listed in the text are split into 13 states. The logic of the split is to differentiate between the different cases given in the conditional statements in the descriptions of each state in the text. In addition, the remote and local states were split for the Unavailable, Protecting failure, and Protecting administrative states.
テーブルを明確にするために、テキストにリストされている6つの州は13の州に分割されます。分割の論理は、テキスト内の各状態の説明の条件付きステートメントに与えられた異なるケースを区別することです。さらに、遠隔地と地方の州は、利用不能のために分割され、失敗を保護し、行政国家を保護しました。
There is only one table for the PSC state machine, but it is broken into two parts for space reasons. The first part lists the 13 possible states, the eight possible local inputs (that is, inputs that are generated by the node in question), and the action taken when a given input is received when the node is in a particular state. The second part of the table lists the 13 possible states and the eight remote inputs (inputs that come from a node other than the one executing the state machine).
PSCステートマシンには1つのテーブルのみがありますが、空間の理由により2つの部分に分割されています。最初の部分には、13の可能な状態、可能な8つのローカル入力（つまり、問題のノードによって生成される入力）、および特定の状態にあるノードが受信されたときに特定の入力が受信されたときに実行されるアクションがリストされています。テーブルの2番目の部分には、13の可能な状態と8つのリモート入力（ステートマシンを実行するノード以外のノードから生じる入力）がリストされています。
There are 13 rows in the table, headers notwithstanding. These rows are the 13 possible extended states in the state machine.
テーブルには13行がありますが、ヘッダーにもかかわらず。これらの行は、州のマシンで可能な13の拡張状態です。
The text in the first column is the current state. Those states that have both source and cause are formatted as State:Cause:Source. For example, the string UA:LO:L indicates that the current state is 'Unavailable', that the cause of the current state is a Lockout of protection that was a local input. In contrast, the state N simply is Normal; there is no need to track the cause for entry into Normal state.
最初の列のテキストは現在の状態です。ソースと原因の両方を持っている状態は、状態としてフォーマットされます：原因：ソース。たとえば、文字列UA：LO：Lは、現在の状態が「利用できない」ことを示します。現在の状態の原因は、ローカル入力である保護のロックアウトであることを示します。対照的に、状態nは単に正常です。通常の状態への入場の原因を追跡する必要はありません。
The 13 extended states, as they appear in the table, are as follows:
テーブルに表示される13の拡張状態は次のとおりです。
N Normal state
UA:LO:L Unavailable state due to local Lockout
UA:P:L Unavailable state due to local SF on protection path
UA:LO:R Unavailable state due to remote Lockout of protection message
UA:P:R Unavailable state due to remote SF message on protection path
PF:W:L Protecting failure state due to local SF on working path
PF:W:R Protecting failure state due to remote SF message on working
path
PA:F:L Protecting administrative state due to local FS operator
command
PA:M:L Protecting administrative state due to local MS operator
command
PA:F:R Protecting administrative state due to remote FS message
PA:M:R Protecting administrative state due to remote MS message
WTR Wait-to-Restore state
DNR Do-not-Revert state
Each state corresponds to the transmission of a particular set of Request, FPath and Path bits. 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 to the state-machine table.
各状態は、特定のリクエストセット、FPATH、およびパスビットの送信に対応しています。以下の表には、一般に各特定の状態で送信されるメッセージを示します。特定の状態で送信されるメッセージが以下の表から逸脱している場合、それは脚注にステートマシンテーブルのテーブルに記載されています。
State REQ(FP,P)
------- ---------
N NR(0,0)
UA:LO:L LO(0,0)
UA:P:L SF(0,0)
UA:LO:R NR(0,0)
UA:P:R NR(0,0)
PF:W:L SF(1,1)
PF:W:R NR(0,1)
PA:F:L FS(1,1)
PA:M:L MS(1,1)
PA:F:R NR(0,1)
PA:M:R NR(0,1)
WTR WTR(0,1)
DNR DNR(0,1)
The top row in each table is the list of possible inputs. The local inputs are as follows:
各テーブルの一番上の行は、可能な入力のリストです。ローカル入力は次のとおりです。
NR No Request OC Operator Clear LO Lockout of protection SF-P Signal Fail on protection path SF-W Signal Fail on working path FS Forced Switch SFc Clear Signal Fail MS Manual Switch WTRExp WTR Expired
nr要求なしocオペレーターのクリア保護のロックアウトSF-p信号のロックアウト保護パスの失敗SF-w信号作動パスで失敗しますfs強制スイッチSFCクリア信号MSマニュアルスイッチWTREXP WTR有効
and the remote inputs are as follows:
そして、リモート入力は次のとおりです。
LO remote LO message SF-P remote SF message indicating protection path SF-W remote SF message indicating working path FS remote FS message MS remote MS message WTR remote WTR message DNR remote DNR message NR remote NR message
LOリモートLOメッセージSF-PリモートSFメッセージ保護パスSF-WリモートSFメッセージワーキングパスFSリモートFSメッセージMSリモートMSメッセージWTRリモートWTRメッセージDNRリモートDNRメッセージNRリモートNRメッセージを示す
Section 4.3.3 refers to some states as 'remote' and some as 'local'. By definition, all states listed in the table of local sources are local states, and all states listed in the table of remote sources are remote states. For example, Section 4.3.3.1 says "A local Lockout of protection input SHALL cause the LER to go into local Unavailable state". As the trigger for this state change is a local one, 'local Unavailable state' is, by definition, displayed in the table of local sources. Similarly, Section 4.3.3.1 also states that
セクション4.3.3では、一部の状態は「リモート」と「ローカル」として言及しています。定義上、ローカルソースのテーブルにリストされているすべての州は地方の州であり、リモートソースのテーブルにリストされているすべての州は遠隔地です。たとえば、セクション4.3.3.1には、「保護入力のローカルロックアウトにより、LERがローカルで利用できない状態になります」と述べています。この状態の変更のトリガーはローカルのものであるため、「ローカルの利用できない状態」は、定義上、ローカルソースの表に表示されます。同様に、セクション4.3.3.1もそれを述べています
"A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state" means that the state represented in the Unavailable rows in the table of remote sources is by definition a remote Unavailable state.
「保護メッセージのリモートロックアウトは、LERをリモート利用できない状態にすることを引き起こすものとします」とは、リモートソースのテーブルの利用できない行に表される状態が定義上、リモート利用不能状態であることを意味します。
Each cell in the table below contains either a state, a footnote, or the letter 'i'. 'i' stands for Ignore, and is an indication to continue with the current behavior. See Section 4.3.3. The footnotes are listed below the table.
下の表の各セルには、状態、脚注、または文字「i」のいずれかが含まれています。「I」は無視の略で、現在の動作を続ける兆候です。セクション4.3.3を参照してください。脚注はテーブルの下にリストされています。
Part 1: Local input state machine
パート1：ローカル入力状態マシン
| OC | LO | SF-P | FS | SF-W | SFc | MS | WTRExp
--------+-----+-------+------+------+------+------+------+-------
N | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
UA:LO:L | N | i | i | i | i | i | i | i
UA:P:L | i |UA:LO:L| i |PA:F:L| i | [5] | i | i
UA:LO:R | i |UA:LO:L| [1] | i | [2] | [6] | i | i
UA:P:R | i |UA:LO:L|UA:P:L|PA:F:L| [3] | [6] | i | i
PF:W:L | i |UA:LO:L|UA:P:L|PA:F:L| i | [7] | i | i
PF:W:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i
PA:F:L | N |UA:LO:L| i | i | i | i | i | i
PA:M:L | N |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i
PA:F:R | i |UA:LO:L| i |PA:F:L| [4] | [8] | i | i
PA:M:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
WTR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| [9]
DNR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
Part 2: Remote messages state machine
パート2：リモートメッセージ状態マシン
| LO | SF-P | FS | SF-W | MS | WTR | DNR | NR
--------+-------+------+------+------+------+------+------+------
N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
UA:LO:L | i | i | i | i | i | i | i | i
UA:P:L | [10] | i | [19] | i | i | i | i | i
UA:LO:R | i | i | i | i | i | i | i | [16]
UA:P:R |UA:LO:R| i |PA:F:R| i | i | i | i | [16]
PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i
PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | N
PA:F:L |UA:LO:R| i | i | i | i | i | i | i
PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i
PA:F:R |UA:LO:R| i | i | i | i | i | DNR | [17]
PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | DNR | N
WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [18]
DNR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
The following are the footnotes for the table:
以下は、テーブルの脚注です。
[1] Remain in the current state (UA:LO:R) and transmit SF(0,0).
[1] 現在の状態（UA：LO：R）に留まり、SF（0,0）を送信します。
[2] Remain in the current state (UA:LO:R) and transmit SF(1,0).
[2] 現在の状態（UA：LO：R）に留まり、SF（1,0）を送信します。
[3] Remain in the current state (UA:P:R) and transmit SF(1,0).
[3] 現在の状態（UA：P：R）に留まり、SF（1,0）を送信します。
[4] Remain in the current state (PA:F:R) and transmit SF(1,1).
[4] 現在の状態（PA：F：R）に留まり、SF（1,1）を送信します。
[5] If the SF being cleared is SF-P, transition to N. If it's SF-W, ignore the clear.
[5] クリアされているSFがSF-Pである場合、Nに移行します。SF-Wの場合は、クリアを無視します。
[6] Remain in current state (UA:x:R), if the SFc corresponds to a previous SF, then begin transmitting NR(0,0).
[6] SFCが以前のSFに対応する場合、現在の状態（UA：X：R）にとどまり、NR（0,0）の送信を開始します。
[7] If domain configured for revertive behavior transition to WTR, else transition to DNR.
[7] revertiveの動作のために構成されたドメインがWTRに移行する場合、それ以外の場合はDNRに移行します。
[8] Remain in PA:F:R and transmit NR(0,1).
[8] PA：f：rにとどまり、NRを送信します（0,1）。
[9] Remain in WTR, send NR(0,1).
[9] WTRにとどまり、NR（0,1）を送信します。
[10] Transition to UA:LO:R continue sending SF(0,0).
[10] UAへの移行：lo：r Sf（0,0）の送信を続けます。
[11] Transition to UA:LO:R and send SF(1,0).
[11] ua：lo：rへの移行とSF（1,0）を送信します。
[12] Transition to UA and send SF(1,0).
[12] UAに移行してSF（1,0）を送信します。
[13] Transition to PF:W:R and send NR(0,1).
[13] PFへの移行：w：rおよび送信nr（0,1）。
[14] Transition to WTR state and continue to send the current message.
[14] WTR状態に移行し、現在のメッセージを送信し続けます。
[15] Transition to DNR state and continue to send the current message.
[15] DNR状態に移行し、現在のメッセージの送信を継続します。
[16] If the local input is SF-P, then transition to UA:P:L. If the local input is SF-W, then transition to PF:W:L. Else, transition to N state and continue to send the current message.
[16] ローカル入力がSF-Pの場合、UA：P：Lに移行します。ローカル入力がSF-Wの場合、PF：W：Lに移行します。そうでなければ、n状態に移行し、現在のメッセージを送信し続けます。
[17] If the local input is SF-W, then transition to PF:W:L. Else, transition to N state and continue to send the current message.
[17] ローカル入力がSF-Wの場合、PF：W：Lに移行します。そうでなければ、n状態に移行し、現在のメッセージを送信し続けます。
[18] If the receiving LER's WTR timer is running, maintain current state and message. If the WTR timer is stopped, transition to N.
[18] 受信LERのWTRタイマーが実行されている場合は、現在の状態とメッセージを維持します。WTRタイマーが停止した場合、Nに移行します。
[19] Transition to PA:F:R and send SF (0,1).
[19] PAへの移行：f：rおよびSEND SF（0,1）。
There is a requirement in [RFC5654] (number 84) that discusses a requirement to verify that the protection path is viable. While the PSC protocol does not define a specific operation for this functionality, it is possible to perform this operation by combining operations of the PSC and other OAM functionalities. One such possible combination would be to issue a Lockout of protection operation and then use the OAM function for diagnostic testing of the protection path. Similarly, to test the paths when the working path is not active would involve performing a Forced Switch to protection and then perform the diagnostic function on either the working or protection path.
[RFC5654]（番号84）には、保護パスが実行可能であることを確認するための要件を議論する要件があります。PSCプロトコルはこの機能の特定の操作を定義していませんが、PSCおよびその他のOAM機能の操作を組み合わせることにより、この操作を実行することができます。そのような可能な組み合わせの1つは、保護操作のロックアウトを発行し、OAM関数を使用して保護パスの診断テストを使用することです。同様に、作業パスがアクティブでない場合にパスをテストするには、強制スイッチを保護に実行し、作業パスまたは保護パスのいずれかで診断機能を実行することが含まれます。
Authors' Addresses
著者のアドレス
Yaacov Weingarten (editor) Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
Yaacov Weingarten（編集者）Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
EMail: yaacov.weingarten@nsn.com
Stewart Bryant Cisco United Kingdom
スチュワート・ブライアント・シスコ・イギリス
EMail: stbryant@cisco.com
Eric Osborne Cisco United States
エリック・オズボーン・シスコ米国
EMail: eosborne@cisco.com
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
EMail: nurit.sprecher@nsn.com
Annamaria Fulignoli (editor) Ericsson Via Moruzzi Pisa 56100 Italy
アナマリア・フリニョーリ（編集者）モルッツィ・ピサ56100イタリア経由のエリクソン
EMail: annamaria.fulignoli@ericsson.com