[要約] RFC 7347は、MPLS Transport Profile（MPLS-TP）における事前標準の線形保護切り替えに関する規格です。このRFCの目的は、MPLS-TPネットワークでの信頼性と回復性を向上させるための保護スイッチングの仕組みを提供することです。
Independent Submission H. van Helvoort, Ed.
Request for Comments: 7347 Huawei Technologies
Category: Informational J. Ryoo, Ed.
ISSN: 2070-1721 ETRI
H. Zhang
Huawei Technologies
F. Huang
Philips
H. Li
China Mobile
A. D'Alessandro
Telecom Italia
September 2014
Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)
MPLSトランスポートプロファイルの先行標準の線形保護スイッチング（MPLS-TP）
Abstract
概要
The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.
MPLSトランスポートプロファイル（MPLS-TP）線形保護のIETF標準トラックソリューションは、RFC 6378、7271、および7324で提供されています。
This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.
このドキュメントでは、複数のベンダーの機器を使用する複数のネットワークオペレータによって導入されたMPLS-TP線形保護の先行標準実装について説明します。公開の時点で、これらの先行標準の実装はまだライブトラフィックを運んで運用されていました。
The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.
指定されたメカニズムは、1 + 1単方向/双方向保護切り替えと1：1双方向保護切り替えをサポートします。これは純粋にMPLS-TPデータプレーンでサポートされており、コントロールプレーンがなくても機能します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7347.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7347で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Linear Protection-Switching Overview . . . . . . . . . . . . 6
4.1. Protection Architecture Types . . . . . . . . . . . . . . 6
4.1.1. 1+1 Architecture . . . . . . . . . . . . . . . . . . 6
4.1.2. 1:1 Architecture . . . . . . . . . . . . . . . . . . 6
4.1.3. 1:n Architecture . . . . . . . . . . . . . . . . . . 7
4.2. Protection Switching Type . . . . . . . . . . . . . . . . 7
4.3. Protection Operation Type . . . . . . . . . . . . . . . . 7
5. Protection-Switching Trigger Conditions . . . . . . . . . . . 8
5.1. Fault Conditions . . . . . . . . . . . . . . . . . . . . 8
5.2. External Commands . . . . . . . . . . . . . . . . . . . . 8
5.2.1. End-to-End Commands . . . . . . . . . . . . . . . . . 8
5.2.2. Local Commands . . . . . . . . . . . . . . . . . . . 9
6. Protection-Switching Schemes . . . . . . . . . . . . . . . . 10
6.1. 1+1 Unidirectional Protection Switching . . . . . . . . . 10
6.2. 1+1 Bidirectional Protection Switching . . . . . . . . . 11
6.3. 1:1 Bidirectional Protection Switching . . . . . . . . . 12
7. APS Protocol . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. APS PDU Format . . . . . . . . . . . . . . . . . . . . . 13
7.2. APS Transmission . . . . . . . . . . . . . . . . . . . . 16
7.3. Hold-Off Timer . . . . . . . . . . . . . . . . . . . . . 17
7.4. WTR Timer . . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. Command Acceptance and Retention . . . . . . . . . . . . 18
7.6. Exercise Operation . . . . . . . . . . . . . . . . . . . 18
8. Protection-Switching Logic . . . . . . . . . . . . . . . . . 19
8.1. Principle of Operation . . . . . . . . . . . . . . . . . 19
8.2. Equal Priority Requests . . . . . . . . . . . . . . . . . 21
8.3. Signal Degrade of the Protection Transport Entity . . . . 22
9. Protection-Switching State Transition Tables . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Operation Examples of the APS Protocol . . . . . . . 26
The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in [RFC6378], [RFC7271], and [RFC7324].
MPLSトランスポートプロファイル（MPLS-TP）線形保護のIETF標準トラックソリューションは、[RFC6378]、[RFC7271]、および[RFC7324]で提供されます。
This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.
このドキュメントでは、複数のベンダーの機器を使用する複数のネットワークオペレータによって導入されたMPLS-TP線形保護の先行標準実装について説明します。公開の時点で、これらの先行標準の実装はまだライブトラフィックを運んで運用されていました。
This implementation was considered in the MPLS WG; however, a different path was chosen.
この実装はMPLS WGで検討されました。ただし、別のパスが選択されました。
This document may be useful in the future if a vendor or operator is trying to interwork with a different vendor or operator who has deployed the pre-standard implementation, and it provides a permanent record of the pre-standard implementation. It is also worth noting that the experience gained during deployment of the implementations of this document was used to refine [RFC7271].
このドキュメントは、ベンダーまたはオペレーターが先行標準の実装を展開した別のベンダーまたはオペレーターと連携しようとし、先行標準の実装の永続的な記録を提供する場合に、将来役立つ可能性があります。また、このドキュメントの実装の展開中に得られた経験が[RFC7271]の改良に使用されたことにも注意する必要があります。
MPLS-TP is defined as the transport profile of MPLS technology to allow its deployment in transport networks. A typical feature of a transport network is that it can provide fast protection switching for end-to-end transport paths and transport path segments. The protection-switching time is generally required to be less than 50 ms to meet the strict requirements of services such as voice, private line, etc.
MPLS-TPは、トランスポートネットワークでの展開を可能にするMPLSテクノロジーのトランスポートプロファイルとして定義されます。トランスポートネットワークの典型的な機能は、エンドツーエンドのトランスポートパスとトランスポートパスセグメントの高速保護スイッチングを提供できることです。保護切り替え時間は、音声や専用回線などのサービスの厳しい要件を満たすために、一般に50ミリ秒未満である必要があります。
The goal of a linear protection-switching mechanism is to satisfy the requirement of fast protection switching for an MPLS-TP network. Linear protection switching means that, for one or more working transport entities (working paths), there is one protection transport entity (protection path), which is disjoint from any of the working transport entities, ready to take over the service transmission when a working transport entity has failed.
線形保護スイッチングメカニズムの目標は、MPLS-TPネットワークの高速保護スイッチングの要件を満たすことです。線形保護スイッチングとは、1つ以上の稼働中のトランスポートエンティティ（稼働パス）に対して、稼働中のトランスポートエンティティとは切り離された1つの保護トランスポートエンティティ（保護パス）があり、稼働中にサービス伝送を引き継ぐ準備ができていることを意味します。トランスポートエンティティが失敗しました。
This document specifies a 1+1 unidirectional protection-switching mechanism for a unidirectional transport entity (either point to point or point to multipoint) as well as a bidirectional point-to-point transport entity and a 1+1/1:1 bidirectional protection-switching mechanism for a point-to-point bidirectional transport entity. Since bidirectional protection switching needs the coordination of the two endpoints of the transport entity, this document also specifies the Automatic Protection Switching (APS) protocol, which is used for this purpose.
このドキュメントでは、単方向トランスポートエンティティ（ポイントツーポイントまたはポイントツーマルチポイント）の1 + 1単方向保護スイッチングメカニズム、および双方向ポイントツーポイントトランスポートエンティティと1 + 1/1：1双方向保護を指定しています。ポイントツーポイント双方向トランスポートエンティティのスイッチングメカニズム。双方向保護切り替えにはトランスポートエンティティの2つのエンドポイントの調整が必要なので、このドキュメントでは、この目的で使用される自動保護切り替え（APS）プロトコルも指定します。
The linear protection mechanism described in this document is applicable to both Label Switched Paths (LSPs) and Pseudowires (PWs).
このドキュメントで説明する線形保護メカニズムは、ラベルスイッチドパス（LSP）と疑似配線（PW）の両方に適用できます。
The APS protocol specified in this document is based on the same principles and behavior of the APS protocol designed for Synchronous Optical Network (SONET) [T1.105.01] / Synchronous Digital Hierarchy (SDH) [G.841], Optical Transport Network (OTN) [G.873.1], and Ethernet [G.8031] and provides commonality with the established operation models utilized in transport network technologies (e.g., SDH/SONET, OTN, and Ethernet).
このドキュメントで指定されているAPSプロトコルは、同期光ネットワーク（SONET）[T1.105.01] /同期デジタル階層（SDH）[G.841]、光トランスポートネットワーク（OTN）用に設計されたAPSプロトコルと同じ原理と動作に基づいています。 ）[G.873.1]、およびイーサネット[G.8031]であり、トランスポートネットワークテクノロジー（SDH / SONET、OTN、イーサネットなど）で利用される確立された運用モデルとの共通性を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
APS Automatic Protection Switching DNR Do not Revert EXER Exercise G-ACh Generic Associated Channel FS Forced Switch LO Lockout of Protection LSP Label Switched Path MPLS-TP MPLS Transport Profile MS Manual Switch MS-P Manual Switch to Protection transport entity MS-W Manual Switch to Working transport entity NR No Request OAM Operations, Administration, and Maintenance OTN Optical Transport Network PDU Protocol Data Unit PW Pseudowire RR Reverse Request SD Signal Degrade SD-P Signal Degrade on Protection transport entity SD-W Signal Degrade on Working transport entity SDH Synchronous Digital Hierarchy SF Signal Fail SF-P Signal Fail on Protection transport entity SF-W Signal Fail on Working transport entity SONET Synchronous Optical Network WTR Wait to Restore
APS自動保護切り替えDNR無効にしないEXER演習G-ACh汎用関連チャネルFS強制切り替えLO保護のロックアウトLSPラベルスイッチドパスMPLS-TP MPLSトランスポートプロファイルMS手動切り替えMS-P手動切り替え保護転送エンティティへの切り替えMS-W手動切り替え現用トランスポートエンティティへNR要求なしOAM運用、管理、およびメンテナンスOTN光トランスポートネットワークPDUプロトコルデータユニットPW疑似配線RR逆要求SD信号劣化SD-P信号保護トランスポートエンティティでの劣化SD-W信号現用トランスポートエンティティでの劣化SDH同期デジタル階層SF信号障害保護トランスポートエンティティのSF-P信号障害SF-W信号が現用トランスポートエンティティの障害SONET同期光ネットワークWTR復元待機
To guarantee the protection-switching time for a working transport entity, its protection transport entity is always preconfigured before the failure occurs. Normally, traffic will be transmitted and received on the working transport entity. Switching to the protection transport entity is usually triggered by link or node failure, external commands, etc. Note that external commands are often used in transport networks by operators, and they are very useful in cases of service adjustment, path maintenance, etc.
動作中のトランスポートエンティティの保護切り替え時間を保証するために、その保護トランスポートエンティティは、障害が発生する前に常に事前構成されています。通常、トラフィックは動作中のトランスポートエンティティで送受信されます。保護トランスポートエンティティへの切り替えは、通常、リンクまたはノードの障害、外部コマンドなどによってトリガーされます。外部コマンドは多くの場合、オペレーターによってトランスポートネットワークで使用され、サービスの調整やパスのメンテナンスなどの場合に非常に役立ちます。
In the 1+1 architecture, the protection transport entity is associated with a working transport entity. The normal traffic is permanently bridged onto both the working transport entity and the protection transport entity at the source endpoint of the protected domain. The normal traffic on working and protection transport entities is transmitted simultaneously to the destination sink endpoint of the protected domain, where a selection between the working and protection transport entity is made based on predetermined criteria, such as signal fail and signal degrade indications.
1 + 1アーキテクチャでは、保護トランスポートエンティティは動作中のトランスポートエンティティに関連付けられています。通常のトラフィックは、保護されたドメインのソースエンドポイントで、動作中のトランスポートエンティティと保護トランスポートエンティティの両方に永続的にブリッジされます。現用および保護トランスポートエンティティの通常のトラフィックは、保護されたドメインの宛先シンクエンドポイントに同時に送信されます。ここで、現用および保護トランスポートエンティティ間の選択は、信号障害や信号劣化の表示などの所定の基準に基づいて行われます。
In the 1:1 architecture, the protection transport entity is associated with a working transport entity. When the working transport entity is determined to be impaired, the normal traffic MUST be transferred from the working to the protection transport entity at both the source and sink endpoints of the protected domain. The selection between the working and protection transport entities is made based on predetermined criteria, such as signal fail and signal degrade indications from the working or protection transport entity.
1：1アーキテクチャでは、保護トランスポートエンティティは動作中のトランスポートエンティティに関連付けられています。現用トランスポートエンティティが障害を起こしていると判断された場合、通常のトラフィックは、保護されたドメインのソースエンドポイントとシンクエンドポイントの両方で、現用トランスポートエンティティから保護トランスポートエンティティに転送される必要があります。現用トランスポートエンティティと保護トランスポートエンティティの間の選択は、現用トランスポートエンティティまたは保護トランスポートエンティティからの信号障害や信号劣化の表示など、所定の基準に基づいて行われます。
The bridge at the source endpoint can be realized in two ways: it is either a selector bridge or a broadcast bridge. With a selector bridge, the normal traffic is connected either to the working transport entity or the protection transport entity. With a broadcast bridge, the normal traffic is permanently connected to the working transport entity, and in case a protection switch is active, it is also connected to the protection transport entity. The broadcast bridge is recommended to be used in revertive mode only.
ソースエンドポイントのブリッジは、セレクタブリッジまたはブロードキャストブリッジの2つの方法で実現できます。セレクタブリッジを使用すると、通常のトラフィックは現用トランスポートエンティティまたは保護トランスポートエンティティに接続されます。ブロードキャストブリッジを使用すると、通常のトラフィックは動作中のトランスポートエンティティに永続的に接続され、保護スイッチがアクティブな場合は、保護トランスポートエンティティにも接続されます。ブロードキャストブリッジは、リバーティブモードでのみ使用することをお勧めします。
Details for the 1:n protection-switching architecture are out of scope of this document and will be provided in a different document in the future.
1：n保護スイッチングアーキテクチャの詳細は、このドキュメントの範囲外であり、将来、別のドキュメントで提供される予定です。
It is worth noting that the APS protocol defined here is capable of supporting 1:n operations.
ここで定義されているAPSプロトコルは1：n操作をサポートできることは注目に値します。
The linear protection-switching types can be a unidirectional switching type or a bidirectional switching type.
線形保護スイッチングタイプには、単方向スイッチングタイプまたは双方向スイッチングタイプがあります。
o Unidirectional switching type: Only the affected direction of the working transport entity is switched to the protection transport entity; the selectors at each endpoint operate independently. This switching type is recommended to be used for 1+1 protection in this document.
o 単方向切り替えタイプ：動作中のトランスポートエンティティの影響を受ける方向のみが保護トランスポートエンティティに切り替えられます。各エンドポイントのセレクターは独立して動作します。このスイッチングタイプは、このドキュメントの1 + 1保護に使用することをお勧めします。
o Bidirectional switching type: Both directions of the working transport entity, including the affected direction and the unaffected direction, are switched to the protection transport entity. For bidirectional switching, the APS protocol is required to coordinate the two endpoints so that both have the same bridge and selector settings, even for a unidirectional failure. This type is applicable for 1+1 and 1:1 protection.
o 双方向スイッチングタイプ：影響を受ける方向と影響を受けない方向を含む、動作中のトランスポートエンティティの両方向が保護トランスポートエンティティに切り替えられます。双方向スイッチングの場合、APSプロトコルは2つのエンドポイントを調整して、片方向障害の場合でも両方が同じブリッジとセレクター設定を持つようにする必要があります。このタイプは、1 + 1および1：1保護に適用されます。
The linear protection operation types can be a non-revertive operation type or a revertive operation type.
線形保護操作タイプには、非復元操作タイプまたは復元操作タイプがあります。
o Non-revertive operation: The normal traffic will not be switched back to the working transport entity even after a protection switching cause has cleared. This is generally accomplished by replacing the previous switch request with a "Do not Revert (DNR)" request, which has a low priority.
o 非リバーティブ操作：保護切り替えの原因が解消された後でも、通常のトラフィックは現用トランスポートエンティティに切り替えられません。これは通常、前の切り替え要求を優先度の低い「元に戻さない（DNR）」要求に置き換えることで実現されます。
o Revertive operation: The normal traffic is restored to the working transport entity after the condition(s) causing the protection switching has cleared. In the case of clearing a command (e.g., Forced Switch), this happens immediately. In the case of clearing a defect, this generally happens after the expiry of a "Wait to Restore (WTR)" timer, which is used to avoid chattering of selectors in the case of intermittent defects.
o 復元操作：保護切り替えの原因となった状態が解消された後、正常なトラフィックが現用トランスポートエンティティに復元されます。コマンド（たとえば、強制切り替え）をクリアする場合、これはすぐに発生します。欠陥をクリアする場合、これは通常、「復元の待機（WTR）」タイマーの期限が切れた後に発生します。これは、断続的な欠陥の場合にセレクターのチャタリングを回避するために使用されます。
Fault conditions mean the requests generated by the local Operations, Administration, and Maintenance (OAM) function.
障害状態とは、ローカルの運用、管理、および保守（OAM）機能によって生成された要求を意味します。
o Signal Fail (SF): If an endpoint detects a failure by an OAM function or other mechanism, it will submit a local signal failure (local SF) to the APS module to request a protection switch. The local SF could be on the working transport entity (Signal Fail on Working transport entity (SF-W)) or the protection transport entity (Signal Fail on Protection transport entity (SF-P)).
o 信号障害（SF）：エンドポイントがOAM機能またはその他のメカニズムによって障害を検出すると、ローカル信号障害（ローカルSF）をAPSモジュールに送信して、保護切り替えを要求します。ローカルSFは、稼働中のトランスポートエンティティ（稼働中のトランスポートエンティティ（SF-W）上の信号障害）または保護トランスポートエンティティ（保護中のトランスポートエンティティ（SF-P）上の信号障害）にある可能性があります。
o Signal Degrade (SD): If an endpoint detects signal degradation by an OAM function or other mechanism, it will submit a local signal degrade (local SD) to the APS module to request a protection switching. The local SD could be on the working transport entity (Signal Degrade on Working transport entity (SD-W)) or the protection transport entity (Signal Degrade on Protection transport entity (SD-P)).
o 信号劣化（SD）：エンドポイントがOAM機能または他のメカニズムによる信号劣化を検出すると、ローカル信号劣化（ローカルSD）をAPSモジュールに送信して、保護切り替えを要求します。ローカルSDは、稼働中のトランスポートエンティティ（稼働中のトランスポートエンティティの信号劣化（SD-W））または保護トランスポートエンティティ（保護中の信号劣化（SD-P））にある可能性があります。
The external command issues an appropriate external request to the protection process.
外部コマンドは、保護プロセスに適切な外部要求を発行します。
These commands are applied to both local and remote nodes. When the APS protocol is present, these commands, except the Clear command, are signaled to the far end of the connection. In bidirectional switching, these commands affect the bridge and selector at both ends.
これらのコマンドは、ローカルノードとリモートノードの両方に適用されます。 APSプロトコルが存在する場合、Clearコマンドを除くこれらのコマンドは、接続の遠端に通知されます。双方向スイッチングでは、これらのコマンドは両端のブリッジとセレクタに影響します。
o Lockout of Protection (LO): This command is used to provide the operator a tool for temporarily disabling access to the protection transport entity.
o 保護のロックアウト（LO）：このコマンドは、保護トランスポートエンティティへのアクセスを一時的に無効にするためのツールをオペレーターに提供するために使用されます。
o Manual Switch (MS): This command is used to provide the operator a tool for temporarily switching normal traffic to the working transport entity (Manual Switch to Working transport entity (MS-W)) or to the protection transport entity (Manual Switch to Protection transport entity (MS-P)), unless a higher priority switch request (i.e., LO, FS, or SF) is in effect.
o 手動切り替え（MS）：このコマンドは、通常のトラフィックを一時的に作業中のトランスポートエンティティ（手動切り替えから作業中のトランスポートエンティティ（MS-W））または保護トランスポートエンティティ（手動切り替えから保護）に切り替えるためのツールをオペレーターに提供するために使用されますより高い優先順位の切り替え要求（つまり、LO、FS、またはSF）が有効になっていない限り、トランスポートエンティティ（MS-P））。
o Forced Switch (FS): This command is used to provide the operator a tool for temporarily switching normal traffic from the working transport entity to the protection transport entity, unless a higher priority switch request (i.e., LO or SF-P) is in effect.
o 強制切り替え（FS）：このコマンドは、優先順位の高い切り替え要求（つまり、LOまたはSF-P）が有効でない限り、通常のトラフィックを現用トランスポートエンティティから保護トランスポートエンティティに一時的に切り替えるためのツールをオペレーターに提供するために使用されます。
o Exercise (EXER): Exercise is a command to test if the APS communication is operating correctly. The EXER command SHALL NOT affect the state of the protection selector and bridge.
o エクササイズ（EXER）：エクササイズは、APS通信が正しく動作しているかどうかをテストするコマンドです。 EXERコマンドは、保護セレクターとブリッジの状態に影響を及ぼしません（SHALL NOT）。
o Clear: This command between management and the local protection process is not a request sent by APS to other endpoints. It is used to clear the active near-end external command or WTR state.
o クリア：管理とローカル保護プロセスの間のこのコマンドは、APSが他のエンドポイントに送信する要求ではありません。アクティブな近端の外部コマンドまたはWTR状態をクリアするために使用されます。
These commands apply only to the near end (local node) of the protection group. Even when an APS protocol is supported, they are not signaled to the far end.
これらのコマンドは、保護グループの近端（ローカルノード）にのみ適用されます。 APSプロトコルがサポートされている場合でも、それらは遠端に通知されません。
o Freeze: This command freezes the state of the protection group. Until the freeze is cleared, additional near-end commands are rejected, and condition changes and received APS information are ignored. When the Freeze command is cleared, the state of the protection group is recomputed based on the condition and received APS information.
o Freeze：このコマンドは、保護グループの状態を凍結します。フリーズが解除されるまで、追加の近端コマンドは拒否され、状態の変化と受信したAPS情報は無視されます。 Freezeコマンドがクリアされると、保護グループの状態は、状態と受信したAPS情報に基づいて再計算されます。
Because the freeze is local, if the freeze is issued at one end only, a failure of protocol can occur as the other end is open to accept any operator command or fault condition.
フリーズはローカルであるため、フリーズが一方の端でのみ発行された場合、他方の端が開いてオペレーターコマンドまたは障害状態を受け入れるため、プロトコルの障害が発生する可能性があります。
o Clear Freeze: This command clears the local freeze.
o Clear Freeze：このコマンドは、ローカルフリーズをクリアします。
+-----------+ +-----------+
| |---------------------------------------| |
| -+---------------------------------------+- |
| / |---------------------------------------| \ |
| / | Working transport entity | \ |
--+-------> | | --------+->
| \ | | |
| \ |---------------------------------------| |
| -+---------------------------------------| |
| source |---------------------------------------| sink |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| -+------------------XX-------------------+ |
| / |---------------------------------------| |
| / | Working transport entity (failure) | |
--|-------> | | --------+->
| \ | | / |
| \ |---------------------------------------| / |
| -+---------------------------------------+- |
| source |---------------------------------------| sink |
+-----------+ Protection transport entity +-----------+
(failure condition)
Figure 1: 1+1 Unidirectional Linear Protection Switching
図1：1 + 1単方向線形保護スイッチング
1+1 unidirectional protection switching is the simplest protection switching mechanism. The normal traffic is permanently bridged on both the working and protection transport entities at the source endpoint of the protected domain. In the normal condition, the sink endpoint receives traffic from the working transport entity. If the sink endpoint detects a failure on the working transport entity, it will switch to receive traffic from the protection transport entity. 1+1 unidirectional protection switching is recommended to be used for unidirectional transport.
1 + 1単方向保護スイッチングは、最も単純な保護スイッチングメカニズムです。通常のトラフィックは、保護されたドメインのソースエンドポイントで、現用と保護の両方のトランスポートエンティティで永続的にブリッジされます。通常の状態では、シンクエンドポイントは動作中のトランスポートエンティティからトラフィックを受信します。シンクエンドポイントが動作中のトランスポートエンティティの障害を検出すると、保護トランスポートエンティティからのトラフィックを受信するように切り替わります。 1 + 1単方向保護スイッチングは、単方向転送に使用することをお勧めします。
Note that 1+1 unidirectional protection switching does not use the APS coordination protocol since it only performs protection switching based on the local request.
1 + 1単方向保護切り替えは、ローカル要求に基づいて保護切り替えのみを実行するため、APS調整プロトコルを使用しないことに注意してください。
+-----------+ +-----------+
| |---------------------------------------| |
| -+<--------------------------------------+- |
| / +-------------------------------------->+ \ |
| sink / /|---------------------------------------|\ \ sink |
<-+-------/ / | Working transport entity | --\-------+->
--+--------> | | <------+--
| source \ | | / source|
| \|---------------------------------------| / |
| +-------------------------------------->| / |
| |<--------------------------------------+- |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| +<----------------XX--------------------+- |
| +-------------------------------------->+ \ |
| /|---------------------------------------| \ |
| source / | Working transport entity (failure) | \ source|
--+--------> | | \<-----+--
<-+------- \ | | --/------+->
| sink \ \|---------------------------------------| / / sink |
| \ +-------------------------------------->+- / |
| --+<--------------------------------------+-/ |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(failure condition)
Figure 2: 1+1 Bidirectional Linear Protection Switching
図2：1 + 1双方向線形保護スイッチング
In 1+1 bidirectional protection switching, for each direction, the normal traffic is permanently bridged on both the working and protection transport entities at the source endpoint of the protected domain. In the normal condition, for each direction, the sink endpoint receives traffic from the working transport entity.
1 + 1双方向保護スイッチングでは、各方向で、通常のトラフィックが、保護されたドメインのソースエンドポイントにある現用および保護トランスポートエンティティの両方で永続的にブリッジされます。通常の状態では、各方向で、シンクエンドポイントは動作中のトランスポートエンティティからトラフィックを受信します。
If the sink endpoint detects a failure on the working transport entity, it will switch to receive traffic from the protection transport entity. It will also send an APS message to inform the sink endpoint on the other direction to switch to receive traffic from the protection transport entity.
シンクエンドポイントが動作中のトランスポートエンティティの障害を検出すると、保護トランスポートエンティティからのトラフィックを受信するように切り替わります。また、APSメッセージを送信して、保護トランスポートエンティティからのトラフィックを受信するように切り替えるように、反対方向のシンクエンドポイントに通知します。
The APS mechanism is necessary to coordinate the two endpoints of the transport entity and to implement 1+1 bidirectional protection switching even for a unidirectional failure.
APSメカニズムは、トランスポートエンティティの2つのエンドポイントを調整し、単方向障害の場合でも1 + 1双方向保護スイッチングを実装するために必要です。
+-----------+ +-----------+
| |---------------------------------------| |
| -+<--------------------------------------+- |
| / +-------------------------------------->+ \ |
| sink / /|---------------------------------------|\ \ source|
<-+-------/ / | Working transport entity | \ <-------+--
--+--------> | | ---------+->
| source | | sink |
| |---------------------------------------| |
| | | |
| | | |
| APS <...................................................> APS |
| |---------------------------------------| |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| | \/ | |
| | /\ | |
| |---------------------------------------| |
| source | Working transport entity (failure) | sink |
--+-------> | | --------+->
<-+------- \ | | / <------+--
| sink \ \ |---------------------------------------| / / source|
| \ -+-------------------------------------->+- / |
| --+<--------------------------------------+-- |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(failure condition)
Figure 3: 1:1 Bidirectional Linear Protection Switching
図3：1：1双方向線形保護スイッチング
In 1:1 bidirectional protection switching, for each direction, the source endpoint sends traffic on either the working transport entity or the protection transport entity. The sink endpoint receives the traffic from the same transport entity on which the source endpoint sends the traffic.
1：1双方向保護スイッチングでは、ソースエンドポイントは、方向ごとに、現用トランスポートエンティティまたは保護トランスポートエンティティのいずれかでトラフィックを送信します。シンクエンドポイントは、ソースエンドポイントがトラフィックを送信するのと同じトランスポートエンティティからトラフィックを受信します。
In the normal condition, for each direction, the source and sink endpoints send and receive traffic from the working transport entity.
通常の状態では、方向ごとに、ソースエンドポイントとシンクエンドポイントが、動作中のトランスポートエンティティとトラフィックを送受信します。
If the sink endpoint detects a failure on the working transport entity, it will switch to send and receive traffic from the protection transport entity. It will also send an APS message to inform the sink endpoint on another direction to switch to send and receive traffic from the protection transport entity.
シンクエンドポイントが動作中のトランスポートエンティティで障害を検出すると、保護トランスポートエンティティとのトラフィックの送受信に切り替わります。また、APSメッセージを送信して、保護トランスポートエンティティとのトラフィックの送受信を切り替えるように別の方向のシンクエンドポイントに通知します。
The APS mechanism is necessary to coordinate the two endpoints of the transport entity and implement 1:1 bidirectional protection switching even for a unidirectional failure.
APSメカニズムは、トランスポートエンティティの2つのエンドポイントを調整し、単方向障害の場合でも1：1の双方向保護スイッチングを実装するために必要です。
This APS protocol is based upon the APS protocol defined in Section 11 of [G.8031]. See that reference for further definition of the Protocol Data Unit (PDU) fields and protocol details beyond the description in this document.
このAPSプロトコルは、[G.8031]のセクション11で定義されたAPSプロトコルに基づいています。このドキュメントの説明以外に、プロトコルデータユニット（PDU）フィールドとプロトコルの詳細の詳細については、そのリファレンスを参照してください。
APS packets MUST be sent over a Generic Associated Channel (G-ACh) as defined in [RFC5586].
[RFC5586]で定義されているように、APSパケットはGeneric Associated Channel（G-ACh）経由で送信する必要があります。
The format of APS PDU is specified in Figure 4 below.
APS PDUのフォーマットは、以下の図4で指定されています。
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|0 0 0 0|0 0 0 0 0 0 0 0| Channel Type (=0x7FFA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| APS Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End TLV |
+-+-+-+-+-+-+-+-+
Figure 4: APS PDU Format
図4：APS PDUフォーマット
The following values MUST be used for APS PDU:
APS PDUには次の値を使用する必要があります。
o Channel Type: The Channel Type MUST be configurable by the implementation. During deployment, the local system administrator provisioned the value 0x7FFA. This is a code point value in the range of experimental Channel Types as described in RFC 5586, Section 10.
o チャネルタイプ：チャネルタイプは、実装によって構成可能である必要があります。展開中に、ローカルシステム管理者は値0x7FFAをプロビジョニングしました。これは、RFC 5586のセクション10で説明されている実験的なチャネルタイプの範囲のコードポイント値です。
o Maintenance Entity group Level (MEL): The MEL value to set and check MUST be configurable. The DEFAULT value MUST be "111". With co-routed bidirectional transport paths, the configured MEL MUST be the same in both directions.
o メンテナンスエンティティグループレベル（MEL）：設定および確認するMEL値は構成可能でなければなりません。 DEFAULT値は「111」である必要があります。共同ルーティングされた双方向トランスポートパスでは、構成されたMELは両方向で同じでなければなりません。
o Version: 0x00
o バージョン：0x00
o OpCode: 0x27 (=0d39)
o OpCode：0x27（= 0d39）
o Flags: 0x00
o フラグ：0x00
o TLV Offset: 4
o TLVオフセット：4
o End TLV: 0x00
o 終了TLV：0x00
The format of the APS-specific information is defined in Figure 5.
APS固有の情報のフォーマットは、図5で定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request|Pr.Type| Requested | Bridged | | |
| / |-+-+-+-| | |T| Reserved(0)|
| State |A|B|D|R| Signal | Signal | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: APS-Specific Information Format
図5：APS固有の情報形式
All bits defined as "Reserved" MUST be transmitted as 0 and ignored on reception.
「予約済み」として定義されたすべてのビットは0として送信され、受信時には無視される必要があります。
o Request/State:
o リクエスト/状態：
The four bits indicate the protection-switching request type. See Figure 6 for the code of each request/state type.
4ビットは、保護切り替え要求タイプを示します。各要求/状態タイプのコードについては、図6を参照してください。
In case that there are multiple protection-switching requests, only the protection-switching request with the highest priority MUST be processed.
複数の保護切り替え要求がある場合、最も優先度の高い保護切り替え要求のみを処理する必要があります。
+------------------------------------+---------------+
| Request/State | Code/Priority |
+------------------------------------+---------------+
|Lockout of Protection (LO) | 1111 (highest)|
+------------------------------------+---------------+
|Signal Fail on Protection (SF-P) | 1110 |
+------------------------------------+---------------+
|Forced Switch (FS) | 1101 |
+------------------------------------+---------------+
|Signal Fail on Working (SF-W) | 1011 |
+------------------------------------+---------------+
|Signal Degrade (SD) | 1001 |
+------------------------------------+---------------+
|Manual Switch (MS) | 0111 |
+------------------------------------+---------------+
|Wait to Restore (WTR) | 0101 |
+------------------------------------+---------------+
|Exercise (EXER) | 0100 |
+------------------------------------+---------------+
|Reverse Request (RR) | 0010 |
+------------------------------------+---------------+
|Do Not Revert (DNR) | 0001 |
+------------------------------------+---------------+
|No Request (NR) | 0000 (lowest) |
+------------------------------------+---------------+
Figure 6: Protection-Switching Request Code/Priority
図6：保護切り替え要求コード/優先度
o Protection Type (Pr.Type):
o 保護タイプ（Pr.Type）：
The four bits are used to specify the protection type.
4ビットは、保護タイプを指定するために使用されます。
A: reserved (set by default to 1)
B: 0 - 1+1 (permanent bridge)
1 - 1:1 (no permanent bridge)
D: 0 - Unidirectional switching
1 - Bidirectional switching
R: 0 - Non-revertive operation
1 - Revertive operation
o Requested Signal:
o リクエストされた信号：
This byte is used to indicate the traffic that the near-end requests to be carried over the protection entity.
このバイトは、近端が保護エンティティを介して伝送されることを要求するトラフィックを示すために使用されます。
value = 0: Null traffic
value = 1: Normal traffic 1
value = 2~255: Reserved
o Bridged Signal:
o ブリッジ信号：
This byte is used to indicate the traffic that is bridged onto the protection entity.
このバイトは、保護エンティティにブリッジされるトラフィックを示すために使用されます。
value = 0: Null traffic
value = 1: Normal traffic 1
value = 2~255: Reserved
o Bridge Type (T):
o ブリッジタイプ（T）：
This bit is used to further specify the type of non-permanent bridge for 1:1 protection switching.
このビットは、1：1保護切り替え用の非永続ブリッジのタイプをさらに指定するために使用されます。
value = 0: Selector bridge
value = 1: Broadcast bridge
o Reserved:
o 予約済み：
This field MUST be set to zero.
このフィールドはゼロに設定する必要があります。
The APS message MUST be transported on the protection transport entity by encapsulation with the protection transport entity label (the label of the LSP used to transport protection traffic). If an endpoint receives APS-specific information from the working transport entity, it MUST ignore this information and MUST report the failure of protocol defect (see Section 8.1) to the operator.
APSメッセージは、保護トランスポートエンティティラベル（保護トラフィックのトランスポートに使用されるLSPのラベル）でカプセル化することにより、保護トランスポートエンティティでトランスポートする必要があります。エンドポイントが動作中のトランスポートエンティティからAPS固有の情報を受信する場合、この情報を無視し、プロトコル障害（セクション8.1を参照）の失敗をオペレーターに報告する必要があります。
A new APS packet MUST be transmitted immediately when a change in the transmitted status occurs. The first three APS packets MUST be transmitted as fast as possible only if the APS information to be transmitted has been changed so that fast protection switching is possible, even if one or two APS packets are lost or corrupted. The interval of the first three APS packets SHOULD be 3.3 ms. APS packets after the first three MUST be transmitted with the interval of 5 seconds.
送信されたステータスに変化が生じた場合、新しいAPSパケットを直ちに送信する必要があります。最初の3つのAPSパケットは、1つまたは2つのAPSパケットが失われたり破損したりした場合でも、高速保護切り替えが可能になるように、送信するAPS情報が変更された場合に限り、できるだけ速く送信する必要があります。最初の3つのAPSパケットの間隔は3.3 msである必要があります。最初の3つの後のAPSパケットは、5秒の間隔で送信する必要があります。
If no valid APS-specific information is received, the last valid received information remains applicable.
有効なAPS固有の情報が受信されない場合、最後に有効な受信情報が引き続き適用されます。
In order to coordinate timing of protection switches at multiple layers, a hold-off timer MAY be required. The purpose is to allow a server-layer protection switch to have a chance to fix the problem before switching at a client layer.
複数の層で保護スイッチのタイミングを調整するには、ホールドオフタイマーが必要になる場合があります。その目的は、サーバー層の保護切り替えが、クライアント層で切り替える前に問題を修正する機会を持つことを可能にすることです。
Each selector SHOULD have a provisioned hold-off timer. The suggested range of the hold-off timer is 0 to 10 seconds in steps of 100 ms (accuracy of +/-5 ms).
各セレクターには、プロビジョニングされたホールドオフタイマーが必要です（SHOULD）。ホールドオフタイマーの推奨範囲は、100 ms刻みで0〜10秒です（精度は+/- 5 ms）。
When a new defect or more severe defect occurs (new SF or SD) on the active transport entity (the transport entity that currently carries and selects traffic), this event will not be reported immediately to protection switching if the provisioned hold-off timer value is non-zero. Instead, the hold-off timer SHALL be started. When the hold-off timer expires, it SHALL be checked whether a defect still exists on the transport entity that started the timer. If it does, that defect SHALL be reported to protection switching. The defect need not be the same one that started the timer.
アクティブなトランスポートエンティティ（現在トラフィックを伝送および選択しているトランスポートエンティティ）で新しい障害またはより深刻な障害（新しいSFまたはSD）が発生した場合、プロビジョニングされたホールドオフタイマー値がこの値である場合、このイベントはすぐに保護スイッチングに報告されません。ゼロ以外です。代わりに、ホールドオフタイマーを開始する必要があります。ホールドオフタイマーが期限切れになると、タイマーを開始したトランスポートエンティティにまだ障害が存在するかどうかを確認する必要があります。もしそうなら、その欠陥は保護スイッチングに報告されるものとする（SHALL）。欠陥は、タイマーを開始したものと同じである必要はありません。
This hold-off timer mechanism SHALL be applied for both working and protection transport entities.
このホールドオフタイマーメカニズムは、機能しているトランスポートエンティティと保護トランスポートエンティティの両方に適用する必要があります。
In revertive mode of operation, to prevent frequent operation of the protection switch due to an intermittent defect, a failed working transport entity MUST become fault free. After the failed working transport entity meets this criterion, a fixed period of time SHALL elapse before a normal traffic signal uses it again. This period, called a WTR period, MAY be configured by the operator in 1 minute steps between 5 and 12 minutes; the default value is 5 minutes. An SF or SD condition will override the WTR. To activate the WTR timer appropriately, even when both ends concurrently detect clearance of SF-W and SD-W, when the local state transits from SF-W or SD-W to No Request (NR) with the requested signal number 1, the previous local state, SF-W or SD-W, MUST be memorized. If both the local state and far-end state are NR with the requested signal number 1, the local state transits to WTR only when the previous local state is SF-W or SD-W. Otherwise, the local state transits to NR with the requested signal number 0.
動作のリバーティブモードでは、断続的な欠陥による保護スイッチの頻繁な動作を防止するために、障害のある動作中のトランスポートエンティティに障害が発生しないようにする必要があります。機能していないトランスポートエンティティがこの基準を満たした後、通常の交通信号が再び使用する前に、一定期間が経過する必要があります。 WTR期間と呼ばれるこの期間は、オペレーターが5〜12分の1分のステップで構成できます。デフォルト値は5分です。 SFまたはSD条件はWTRをオーバーライドします。 WTRタイマーを適切にアクティブ化するには、両端が同時にSF-WとSD-Wのクリアランスを検出した場合でも、ローカル状態がSF-WまたはSD-Wから要求された信号番号1のNo Request（NR）に遷移するとき、以前のローカル状態、SF-WまたはSD-Wを記憶する必要があります。ローカル状態と遠端状態の両方が要求された信号番号1でNRである場合、ローカル状態は、前のローカル状態がSF-WまたはSD-Wである場合にのみWTRに遷移します。それ以外の場合、ローカル状態は、要求されたシグナル番号0でNRに遷移します。
In revertive mode of operation, when the protection is no longer requested, i.e., the failed working transport entity is no longer in SF or SD condition (and assuming no other requesting transport entities), a local WTR state will be activated. Since this state becomes the highest in priority, it is indicated on the APS signal and maintains the normal traffic signal from the previously failed working transport entity on the protection transport entity. This state SHALL normally time out and become an NR state. The WTR timer deactivates earlier when any request of higher priority request preempts this state.
リバーティブモードの動作では、保護が要求されなくなった場合、つまり、障害が発生した動作中のトランスポートエンティティがSFまたはSD状態ではなくなった場合（および他の要求しているトランスポートエンティティがない場合）、ローカルWTR状態がアクティブになります。この状態は優先度が最も高くなるため、APS信号に示され、保護トランスポートエンティティで以前に障害が発生した動作中のトランスポートエンティティからの通常のトラフィック信号を維持します。この状態は通常タイムアウトし、NR状態になります。優先度の高いリクエストのリクエストがこの状態を横取りすると、WTRタイマーはより早く非アクティブになります。
The commands Clear, LO, FS, MS, and EXER are accepted or rejected in the context of previous commands, the condition of the working and protection entities in the protection group, and (in bidirectional switching only) the APS information received.
コマンドClear、LO、FS、MS、およびEXERは、前のコマンド、保護グループ内の作業エンティティと保護エンティティの状態、および（双方向スイッチングの場合のみ）受信したAPS情報のコンテキストで受け入れまたは拒否されます。
The Clear command MUST be only valid if a near-end LO, FS, MS, or EXER command is in effect or if a WTR state is present at the near end and rejected otherwise. This command will remove the near-end command or WTR state, allowing the next lower-priority condition or (in bidirectional switching) APS request to be asserted.
Clearコマンドは、近端のLO、FS、MS、またはEXERコマンドが有効な場合、またはWTR状態が近端に存在し、それ以外の場合は拒否された場合にのみ有効でなければなりません。このコマンドは、近端コマンドまたはWTR状態を削除し、次に優先順位の低い条件または（双方向スイッチングの場合）APS要求をアサートできるようにします。
Other commands MUST be rejected unless they are higher priority than the previously existing command, condition, or (in bidirectional switching) APS request. If a new command is accepted, any previous, lower-priority command that is overridden MUST be forgotten. If a higher priority command overrides a lower-priority condition or (in bidirectional switching) APS request, that other request will be reasserted if it still exists at the time the command is cleared. If a command is overridden by a condition or (in bidirectional switching) APS request, that command MUST be forgotten.
他のコマンドは、既存のコマンド、条件、または（双方向スイッチングの場合）APS要求よりも優先度が高い場合を除き、拒否する必要があります。新しいコマンドが受け入れられた場合、オーバーライドされる以前の優先順位の低いコマンドはすべて忘れる必要があります。優先順位の高いコマンドが優先順位の低い条件または（双方向スイッチングの場合）APS要求をオーバーライドする場合、コマンドがクリアされたときにその要求がまだ存在していれば、その要求は再アサートされます。コマンドが条件または（双方向スイッチングで）APS要求によってオーバーライドされた場合、そのコマンドを忘れてはなりません（MUST）。
Exercise is a command to test if the APS communication is operating correctly. It is lower priority than any "real" switch request. It is only valid in bidirectional switching, since this is the only place where you can get a meaningful test by looking for a response.
演習は、APS通信が正しく動作しているかどうかをテストするコマンドです。これは、「実際の」切り替え要求よりも優先度が低くなります。これは、応答を探すことによって意味のあるテストを取得できる唯一の場所であるため、双方向スイッチングでのみ有効です。
The Exercise command SHALL issue the command with the same requested and bridged signal numbers of the NR, Reverse Request (RR), or DNR request that it replaces. The valid response will be an RR with the corresponding requested and bridged signal numbers. When Exercise commands are input at both ends, an EXER, instead of RR, MUST be transmitted from both ends. The standard response to DNR MUST be DNR rather than NR. When the exercise command is cleared, it MUST be replaced with NR or RR if the requested signal number is 0 and DNR or RR if the requested signal number is 1.
エクササイズコマンドは、NR、リバースリクエスト（RR）、またはDNRリクエストの同じリクエストされ、ブリッジされたシグナル番号でコマンドを発行する必要があります（SHALL）。有効な応答は、対応する要求され、ブリッジされたシグナル番号を持つRRです。運動コマンドが両端で入力されるとき、RRの代わりにEXERが両端から送信されなければなりません。 DNRへの標準応答は、NRではなくDNRでなければなりません。運動コマンドがクリアされると、要求された信号番号が0の場合はNRまたはRRに、要求された信号番号が1の場合はDNRまたはRRに置き換える必要があります。
+-------------+ Persistent +----------+
SF,SD | Hold-off | fault | Local |
----------->| timer logic |----------->| request |
+-------------+ | logic |
Other local requests ----------------->| |
(LO, FS, MS, EXER, Clear) +----------+
|
| Highest
| local request
|
Remote APS V
message +-------+ Remote APS +----------------+
------------->| APS | request/state | APS process |
(received | check |-------------->| logic |
from far end) +-------+ +----------------+
| ^ | |
| | | Signaled |
| | | APS |
| | Txed | |
| | "Requested V |
| | Signal" +-----------+ |
| +-----------------| APS mess. | |
| | generator | |
| +-----------+ |
| | |
V | |
Failure of V |
protocol APS message |
detection V
Set local
bridge/selector
Figure 7: Protection-Switching Logic
図7：保護切り替えロジック
Figure 7 describes the protection-switching logic.
図7は、保護切り替えロジックを示しています。
One or more local protection-switching requests may be active. The "local request logic" determines which of these requests is highest using the order of priority given in Figure 6. This highest local request information SHALL be passed on to the "APS process logic". Note that an accepted Clear command, clearance of SF or SD, or expiration of the WTR timer SHALL NOT be processed by the local request logic but SHALL be considered as the highest local request and submitted to the APS process logic for processing.
1つ以上のローカル保護切り替え要求がアクティブになっている可能性があります。 「ローカルリクエストロジック」は、図6に示す優先順位を使用して、これらのリクエストのどれが最も高いかを決定します。この最も高いローカルリクエスト情報は、「APSプロセスロジック」に渡される必要があります。受け入れられたクリアコマンド、SFまたはSDのクリアランス、またはWTRタイマーの期限切れは、ローカルリクエストロジックでは処理されないものとしますが、最上位のローカルリクエストと見なされ、処理のためにAPSプロセスロジックに送信される必要があります。
The remote APS message is received from the far end and is subjected to the validity check and mismatch detection in "APS check". Failure of protocol situations are as follows:
リモートAPSメッセージは遠端から受信され、「APSチェック」で有効性チェックと不一致検出が行われます。プロトコル状況の失敗は次のとおりです。
o The "B" field mismatch due to incompatible provisioning;
o 互換性のないプロビジョニングによる「B」フィールドの不一致。
o The reception of the APS message from the working entity due to working/protection configuration mismatch;
o 動作中/保護構成の不一致による動作中のエンティティからのAPSメッセージの受信。
o No match in sent "Requested Signal" and received "Requested Signal" for more than 50 ms;
o 送信された「要求された信号」と受信された「要求された信号」が50ミリ秒を超えて一致しない。
o No APS message is received on the protection transport entity during at least 3.5 times the long APS interval (e.g., at least 17.5 seconds), and there is no defect on the protection transport entity.
o 長いAPS間隔の少なくとも3.5倍（たとえば、少なくとも17.5秒）の間、保護トランスポートエンティティでAPSメッセージは受信されず、保護トランスポートエンティティに欠陥はありません。
Provided the "B" field matches:
「B」フィールドが一致した場合：
o If the "D" bit mismatches, the bidirectional side will fall back to unidirectional switching.
o 「D」ビットが一致しない場合、双方向側は単方向スイッチングにフォールバックします。
o If the "R" bit mismatches, one side will clear switches to WTR and the other will clear to DNR. The two sides will interwork and the traffic is protected.
o 「R」ビットが一致しない場合、片側はスイッチをWTRにクリアし、もう一方はDNRにクリアします。双方が相互作用し、トラフィックが保護されます。
o If the "T" bit mismatches, the side using a broadcast bridge will fall back to using a selector bridge.
o 「T」ビットが一致しない場合、ブロードキャストブリッジを使用する側はセレクタブリッジを使用するようにフォールバックします。
The APS message with invalid information MUST be ignored, and the last valid received information remains applicable.
無効な情報を含むAPSメッセージは無視されなければならず（MUST）、最後に受信した有効な情報が引き続き適用されます。
The linear protection-switching algorithm SHALL commence immediately every time one of the input signals changes, i.e., when the status of any local request changes, or when different APS-specific information is received from the far end. The consequent actions of the algorithm are also initiated immediately, i.e., change the local bridge/selector position (if necessary), transmit new APS-specific information (if necessary), or detect the failure of protocol defect if the protection switching is not completed within 50 ms.
線形保護スイッチングアルゴリズムは、入力信号の1つが変化するたびに、つまり、ローカル要求のステータスが変化したとき、または異なるAPS固有の情報が遠端から受信されたときに、直ちに開始する必要があります。アルゴリズムの結果として生じるアクションもすぐに開始されます。つまり、ローカルブリッジ/セレクターの位置を変更する（必要な場合）、新しいAPS固有の情報を送信する（必要な場合）、または保護切り替えが完了していない場合はプロトコル障害の障害を検出します。 50ミリ秒以内。
The state transition is calculated in the "APS process logic" based on the highest local request, the request of the last received "Request/State" information, and state transition tables defined in Section 9, as follows:
状態遷移は、最も高いローカル要求、最後に受信した「要求/状態」情報の要求、およびセクション9で定義されている状態遷移表に基づいて、「APSプロセスロジック」で次のように計算されます。
o If the highest local request is Clear, clearance of SF or SD, or expiration of WTR, a state transition is calculated first based on the highest local request and state machine table for local requests to obtain an intermediate state. This intermediate state is the final state in case of clearance of SF-P; otherwise, starting at this intermediate state, the last received far-end request and the state machine table for far-end requests are used to calculate the final state.
o 最高のローカル要求がクリア、SFまたはSDのクリアランス、またはWTRの期限切れの場合、中間状態を取得するためのローカル要求の最高のローカル要求と状態マシンテーブルに基づいて、まず状態遷移が計算されます。この中間状態は、SF-Pのクリアランスの場合の最終状態です。それ以外の場合は、この中間状態から始めて、最後に受信した遠端要求と遠端要求の状態マシンテーブルを使用して、最終状態を計算します。
o If the highest local request is neither Clear nor clearance of SF or of SD nor expiration of WTR, the APS process logic compares the highest local request with the request of the last received "Request/State" information based on Figure 6.
o 最上位のローカル要求がクリアでもクリアランスでもSDでもSDでもWTRの期限切れでもない場合、APSプロセスロジックは、最上位のローカル要求を、最後に受信した「要求/状態」情報の要求と図6に基づいて比較します。
1. If the highest local request has higher or equal priority, it is used with the state transition table for local requests defined in Section 9 to determine the final state; otherwise,
1. 最も高いローカルリクエストの優先度が高いか等しい場合、セクション9で定義されているローカルリクエストの状態遷移表とともに使用され、最終的な状態が決定されます。さもないと、
2. The request of the last received "Request/State" information is used with the state transition table for far-end requests defined in Section 9 to determine the final state.
2. 最後に受信した「要求/状態」情報の要求は、セクション9で定義された遠端要求の状態遷移表で使用され、最終状態を決定します。
The "APS message generator" generates APS-specific information with the signaled APS information for the final state from the state transition calculation (with coding as described in Figure 5).
「APSメッセージジェネレーター」は、状態遷移計算からの最終状態のシグナリングされたAPS情報を使用して、APS固有の情報を生成します（図5で説明されているコーディングを使用）。
In general, once a switch has been completed due to a request, it will not be overridden by another request of the same priority (first-come, first-served policy). Equal priority requests from both sides of a bidirectional protection group are both considered valid, as follows:
一般に、要求のために切り替えが完了すると、同じ優先順位の別の要求（先着順のポリシー）によって上書きされることはありません。次のように、双方向保護グループの両側からの等しい優先度の要求はどちらも有効と見なされます。
o If the local state is NR, with the requested signal number 1, and the far-end state is NR, with the requested signal number 0, the local state transits to NR with the requested signal number 0. This applies to the case when the remote request for switching to the protection transport entity has been cleared.
o ローカル状態がNRであり、要求された信号番号1であり、遠端状態がNRであり、要求された信号番号0である場合、ローカル状態は、要求された信号番号0でNRに遷移します。これは、保護トランスポートエンティティへの切り替えのリモート要求はクリアされました。
o If both the local and far-end states are NR, with the requested signal number 1, the local state transits to the appropriate new state (DNR state for non-revertive mode and WTR state for revertive mode). This applies to the case when the old request has been cleared at both ends.
o ローカル状態と遠端状態の両方がNRで、要求された信号番号が1の場合、ローカル状態は適切な新しい状態（非リバーティブモードの場合はDNR状態、リバーティブモードの場合はWTR状態）に遷移します。これは、古い要求が両端でクリアされた場合に適用されます。
o If both the local and far-end states are RR, with the same requested signal number, both ends transit to the appropriate new state according to the requested signal number. This applies to the case of concurrent deactivation of EXER from both ends.
o ローカルと遠端の両方の状態がRRで、要求された信号番号が同じ場合、両端は要求された信号番号に従って適切な新しい状態に遷移します。これは、両端からEXERを同時に非アクティブ化する場合に適用されます。
o In other cases, no state transition occurs, even if equal priority requests are activated from both ends. Note that if MSs are issued simultaneously to both working and protection transport entities, either as local or far-end requests, the MS to the working transport entity is considered as having higher priority than the MS to the protection transport entity.
o それ以外の場合、優先度の等しい要求が両端からアクティブ化されても、状態遷移は発生しません。 MSがローカルトランスポートエンティティと保護トランスポートエンティティの両方に同時に発行される場合、ローカルまたは遠端の要求として、現用トランスポートエンティティに対するMSは、保護トランスポートエンティティに対するMSよりも優先度が高いと見なされます。
Signal degrade on the protection transport entity has the same priority as signal degrade on the working transport entity. As a result, if an SD condition affects both transport entities, the first SD detected MUST NOT be overridden by the second SD detected. If the SD is detected simultaneously, either as local or far-end requests on both working and protection transport entities, then the SD on the standby transport entity MUST be considered as having higher priority than the SD on the active transport entity, and the normal traffic signal continues to be selected from the active transport entity (i.e., no unnecessary protection switching is performed).
保護トランスポートエンティティでの信号劣化は、現用トランスポートエンティティでの信号劣化と同じ優先度を持ちます。その結果、SD状態が両方のトランスポートエンティティに影響を与える場合、最初に検出されたSDが2番目に検出されたSDによって上書きされてはなりません（MUST NOT）。 SDが、ワーキングトランスポートエンティティと保護トランスポートエンティティの両方でローカルまたは遠端要求として同時に検出された場合、スタンバイトランスポートエンティティのSDは、アクティブトランスポートエンティティのSDよりも優先度が高く、通常トラフィック信号はアクティブなトランスポートエンティティから引き続き選択されます（つまり、不要な保護切り替えは実行されません）。
In the preceding sentence, "simultaneously" relates to the occurrence of SD on both the active and standby transport entities at input to the protection-switching process at the same time, or as long as an SD request has not been acknowledged by the remote end in bidirectional protection switching.
前の文では、「同時に」は、保護切り替えプロセスへの入力時のアクティブトランスポートエンティティとスタンバイトランスポートエンティティの両方でのSDの発生と同時に、またはSD要求がリモートエンドによって確認されていない限り発生します。双方向保護スイッチング。
In this section, state transition tables for the following protection switching configurations are described.
このセクションでは、次の保護切り替え構成の状態遷移表について説明します。
o 1:1 bidirectional (revertive mode, non-revertive mode);
o 1：1双方向（リバーティブモード、非リバーティブモード）;
o 1+1 bidirectional (revertive mode, non-revertive mode);
o 1 + 1双方向（リバーティブモード、非リバーティブモード）;
o 1+1 unidirectional (revertive mode, non-revertive mode).
o 1 + 1単方向（リバーティブモード、非リバーティブモード）。
Note that any other global or local request that is not described in state transition tables does not trigger any state transition.
状態遷移表に記載されていない他のグローバルまたはローカル要求は、状態遷移をトリガーしないことに注意してください。
The states specified in the state transition tables can be described as follows:
状態遷移表で指定される状態は、次のように説明できます。
o NR: NR is the state entered by the local priority under all conditions where no local protection-switching requests (including WTR and DNR) are active. NR can also indicate that the highest local request is overridden by the far-end request, whose priority is higher than the highest local request. Normal traffic signal is selected from the corresponding transport entity.
o NR：NRは、ローカル保護切り替え要求（WTRおよびDNRを含む）がアクティブでないすべての条件下で、ローカル優先順位によって入力される状態です。 NRは、最も高いローカル要求が、最も高いローカル要求よりも優先度が高い遠端の要求によって上書きされることを示すこともできます。通常の交通信号は、対応するトランスポートエンティティから選択されます。
o LO, SF-P, SD-P: The access by the normal traffic to the protection transport entity is NOT allowed in this state. The normal traffic is carried by the working transport entity, regardless of the fault/degrade condition possibly present (due to the highest priority of the switching triggers leading to this state).
o LO、SF-P、SD-P：通常のトラフィックによる保護トランスポートエンティティへのアクセスは、この状態では許可されません。通常のトラフィックは、存在する可能性のある障害/劣化状態に関係なく、動作中のトランスポートエンティティによって運ばれます（この状態につながるスイッチングトリガーの優先度が最も高いため）。
o FS, SF-W, SD-W, MS-W, MS-P: A switching trigger NOT resulting in the protection transport entity unavailability is present. The normal traffic is selected either from the corresponding working transport entity or from the protection transport entity, according to the behavior of the specific switching trigger.
o FS、SF-W、SD-W、MS-W、MS-P：切り替えトリガーが原因で、保護トランスポートエンティティを利用できません。通常のトラフィックは、特定のスイッチングトリガーの動作に従って、対応する現用トランスポートエンティティまたは保護トランスポートエンティティから選択されます。
o WTR: In revertive operation, after the clearing of an SF-W or SD-W, this maintains normal traffic as selected from the protection transport entity until the WTR timer expires or another request with higher priority, including the Clear command, is received. This is used to prevent frequent operation of the selector in the case of intermittent failures.
o WTR：リバーティブ操作では、SF-WまたはSD-Wのクリア後、WTRタイマーが期限切れになるか、Clearコマンドを含むより優先度の高い別の要求が受信されるまで、保護トランスポートエンティティから選択された通常のトラフィックを維持します。これは、断続的な障害が発生した場合にセレクタが頻繁に動作するのを防ぐために使用されます。
o DNR: In non-revertive operation, this is used to maintain a normal traffic to be selected from the protection transport entity.
o DNR：非リバーティブ操作では、これは、保護トランスポートエンティティから選択される通常のトラフィックを維持するために使用されます。
o EXER: Exercise of the APS protocol.
o EXER：APSプロトコルの練習。
o RR: The near end will enter and signal Reverse Request only in response to an EXER from the far end.
o RR：近端は、遠端からのEXERに応答してのみ、リバースリクエストに入り、信号を送ります。
[State transition tables are shown at the end of the PDF form of this document.]
[状態遷移表は、このドキュメントのPDFフォームの最後に表示されています。]
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つのドキュメントで説明されているセキュリティメカニズムに大きく依存しています。
The authors would like to thank Hao Long, Vincenzo Sestito, Italo Busi, Igor Umansky, and Andy Malis for their input to and review of the current document.
著者は、現在のドキュメントへの入力とレビューについて、Hao Long、Vincenzo Sestito、Italo Busi、Igor Umansky、およびAndy Malisに感謝します。
[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]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、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月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[G.841] International Telecommunications Union, "Types and characteristics of SDH network protection architectures", ITU-T Recommendation G.841, October 1998.
[G.841]国際電気通信連合、「SDHネットワーク保護アーキテクチャのタイプと特性」、ITU-T勧告G.841、1998年10月。
[G.873.1] International Telecommunications Union, "Optical Transport Network (OTN): Linear protection", ITU-T Recommendation G.873.1, May 2014.
[G.873.1]国際電気通信連合、「光トランスポートネットワーク（OTN）：線形保護」、ITU-T勧告G.873.1、2014年5月。
[G.8031] International Telecommunications Union, "Ethernet linear protection switching", ITU-T Recommendation G.8031/Y.1342, June 2011.
[G.8031]国際電気通信連合、「イーサネット線形保護スイッチング」、ITU-T勧告G.8031 / Y.1342、2011年6月。
[T1.105.01] American National Standards Institute, "Synchronous Optical Network (SONET) - Automatic Protection Switching", ANSI 0900105.01:2000 (R2010), March 2000.
[T1.105.01] American National Standards Institute、「Synchronous Optical Network（SONET）-Automatic Protection Switching」、ANSI 0900105.01：2000（R2010）、2000年3月。
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC6378] Weingarten、Y.、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、2011年10月。
[RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, June 2014.
[RFC7271] Ryoo、J.、Gray、E.、van Helvoort、H.、D'Alessandro、A.、Cheung、T。、およびE. Osborne、「MPLS Transport Profile（MPLS-TP）Linear Protection to Match the同期デジタル階層、光トランスポートネットワーク、およびイーサネットトランスポートネットワークオペレーターの運用上の期待」、RFC 7271、2014年6月。
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, July 2014.
[RFC7324] Osborne、E。、「Updates to MPLS Transport Profile Linear Protection」、RFC 7324、2014年7月。
The sequence diagrams shown in this section are only a few examples of the APS operations. The first APS message, which differs from the previous APS message, is shown. The operation of hold-off timer is omitted. The fields whose values are changed during APS packet exchange are shown in the APS packet exchange. They are Request/ State, requested traffic, and bridged traffic. For an example, SF(0,1) represents an APS packet with the following field values: Request/State = SF, Requested Signal = 0, and Bridged Signal = 1. The values of the other fields remain unchanged from the initial configuration. The signal numbers 0 and 1 refer to null signal and normal traffic signal, respectively. W(A->Z) and P(A->Z) indicate the working and protection paths in the direction of A to Z, respectively.
このセクションに示すシーケンス図は、APS操作のほんの数例です。前のAPSメッセージとは異なる最初のAPSメッセージが表示されます。ホールドオフタイマーの動作は省略しています。 APSパケット交換中に値が変更されるフィールドは、APSパケット交換に表示されます。それらは、要求/状態、要求されたトラフィック、およびブリッジされたトラフィックです。たとえば、SF（0,1）は次のフィールド値を持つAPSパケットを表します：要求/状態= SF、要求された信号= 0、およびブリッジ信号=1。他のフィールドの値は初期構成から変更されないままです。信号番号0と1は、それぞれヌル信号と通常の交通信号を表します。 W（A-> Z）およびP（A-> Z）は、それぞれAからZの方向の現用パスと保護パスを示します。
Example 1. 1:1 bidirectional protection switching (revertive mode) - Unidirectional SF case
例1. 1：1双方向保護スイッチング（リバーティブモード）-単方向SFケース
A Z
| |
(1) |---- NR(0,0)----->|
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3)
|<----- NR(1,1)----|
(4) | |
| |
(5) | (Recovery) |
|---- WTR(1,1)---->|
/| |
WTR timer | |
\| |
(6) |---- NR(0,0)----->| (7)
(8) |<----- NR(0,0)----|
| |
(1) The protected domain is operating without any defect, and the working entity is used for delivering the normal traffic.
（1）保護されたドメインは問題なく動作しており、正常なトラフィックの配信には現用エンティティが使用されています。
(2) Signal Fail occurs on the working entity in the Z to A direction. Selector and bridge of node A select protection entity. Node A generates an SF(1,1) message.
（2）ZからA方向の動作エンティティで信号障害が発生します。ノードAのセレクターとブリッジは、保護エンティティを選択します。ノードAはSF（1,1）メッセージを生成します。
(3) Upon receiving SF(1,1), node Z sets selector and bridge to protection entity. As there is no local request in node Z, node Z generates an NR(1,1) message.
（3）SF（1,1）を受信すると、ノードZはセレクタとブリッジを保護エンティティに設定します。ノードZにはローカル要求がないため、ノードZはNR（1,1）メッセージを生成します。
(4) Node A confirms that the far end is also selecting protection entity.
（4）ノードAは、遠端も保護エンティティを選択していることを確認します。
(5) Node A detects clearing of the SF condition, starts the WTR timer, and sends a WTR(1,1) message.
（5）ノードAは、SF状態のクリアを検出し、WTRタイマーを開始し、WTR（1,1）メッセージを送信します。
(6) At expiration of the WTR timer, node A sets selector and bridge to working entity and sends an NR(0,0) message.
（6）WTRタイマーの満了時に、ノードAはセレクターとブリッジを作業エンティティーに設定し、NR（0,0）メッセージを送信します。
(7) Node Z is notified that the far-end request has been cleared and sets selector and bridge to working entity.
（7）ノードZは、遠端要求がクリアされたことを通知され、セレクタとブリッジを動作中のエンティティに設定します。
(8) It is confirmed that the far end is also selecting working entity.
（8）遠端でも実体を選択していることを確認。
Example 2. 1:1 bidirectional protection switching (revertive mode) - Bidirectional SF case
例2. 1：1双方向保護スイッチング（リバーティブモード）-双方向SFケース
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | WTR timer
\| |/
(6) |<---- NR(1,1)---->| (6)
(7) |<----- NR(0,0)--->| (7)
(8) | | (8)
(1) The protected domain is operating without any defect, and the working entity is used for delivering the normal traffic.
（1）保護されたドメインは問題なく動作しており、正常なトラフィックの配信には現用エンティティが使用されています。
(2) Nodes A and Z detect local SF conditions on the working entity, set selector and bridge to protection entity, and generate SF(1,1) messages.
（2）ノードAおよびZは、動作中のエンティティのローカルSF状態を検出し、セレクタとブリッジを保護エンティティに設定し、SF（1,1）メッセージを生成します。
(3) Upon receiving SF(1,1), each node confirms that the far end is also selecting protection entity.
（3）SF（1,1）を受信すると、各ノードは遠端も保護エンティティを選択していることを確認します。
(4) Each node detects clearing of the SF condition and sends an NR(1,1) message as the last received APS message was SF.
（4）最後に受信したAPSメッセージがSFだったため、各ノードはSF状態のクリアを検出し、NR（1,1）メッセージを送信します。
(5) Upon receiving NR(1,1), each node starts the WTR timer and sends WTR(1,1).
（5）各ノードはNR（1,1）を受信すると、WTRタイマーを開始し、WTR（1,1）を送信します。
(6) At expiration of the WTR timer, each node sends NR(1,1) as the last received APS message was WTR.
（6）WTRタイマーの満了時に、最後に受信したAPSメッセージがWTRだったため、各ノードはNR（1,1）を送信します。
(7) Upon receiving NR(1,1), each node sets selector and bridge to working entity and sends an NR(0,0) message.
（7）NR（1,1）を受信すると、各ノードはセレクターとブリッジを動作エンティティに設定し、NR（0,0）メッセージを送信します。
(8) It is confirmed that the far end is also selecting working entity.
（8）遠端でも実体を選択していることを確認。
Example 3. 1:1 bidirectional protection switching (revertive mode) - Bidirectional SF case - Inconsistent WTR timers
例3. 1：1双方向保護切り替え（リバーティブモード）-双方向SFケース-一貫性のないWTRタイマー
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | |
\| | WTR timer
(6) |----- NR(1,1)---->| | (7)
| |/
(9) |<----- NR(0,0)----| (8)
|---- NR(0,0)----->| (10)
(1) The protected domain is operating without any defect, and the working entity is used for delivering the normal traffic.
（1）保護されたドメインは問題なく動作しており、正常なトラフィックの配信には現用エンティティが使用されています。
(2) Nodes A and Z detect local SF conditions on the working entity, set selector and bridge to protection entity, and generate SF(1,1) messages.
（2）ノードAおよびZは、動作中のエンティティのローカルSF状態を検出し、セレクタとブリッジを保護エンティティに設定し、SF（1,1）メッセージを生成します。
(3) Upon receiving SF(1,1), each node confirms that the far end is also selecting protection entity.
（3）SF（1,1）を受信すると、各ノードは遠端も保護エンティティを選択していることを確認します。
(4) Each node detects clearing of the SF condition and sends an NR(1,1) message as the last received APS message was SF.
（4）最後に受信したAPSメッセージがSFだったため、各ノードはSF状態のクリアを検出し、NR（1,1）メッセージを送信します。
(5) Upon receiving NR(1,1), each node starts the WTR timer and sends WTR(1,1).
（5）各ノードはNR（1,1）を受信すると、WTRタイマーを開始し、WTR（1,1）を送信します。
(6) At expiration of the WTR timer in node A, node A sends an NR(1,1) message as the last received APS message was WTR.
（6）ノードAのWTRタイマーの満了時に、最後に受信したAPSメッセージがWTRだったので、ノードAはNR（1,1）メッセージを送信します。
(7) At node Z, the received NR(1,1) is ignored as the local WTR has a higher priority.
（7）ノードZでは、ローカルWTRの優先度が高いため、受信したNR（1,1）は無視されます。
(8) At expiration of the WTR timer in node Z, node Z sets selector and bridge to working entity and sends an NR(0,0) message.
（8）ノードZのWTRタイマーの満了時に、ノードZはセレクターとブリッジを動作中のエンティティに設定し、NR（0,0）メッセージを送信します。
(9) Upon receiving NR(0,0), node A sets selector and bridge to working entity and sends an NR(0,0) message.
（9）NR（0,0）を受信すると、ノードAはセレクターとブリッジを作業エンティティに設定し、NR（0,0）メッセージを送信します。
(10) It is confirmed that the far end is also selecting working entity.
（10）遠端でも実体を選択していることを確認。
Example 4. 1:1 bidirectional protection switching (non-revertive mode) - Unidirectional SF on working followed by unidirectional SF on protection
例4. 1：1双方向保護スイッチング（非リバーティブモード）-動作中の単方向SFに続いて保護上の単方向SF
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|----- SF(1,1)---->| (3)
(4) |<----- NR(1,1)----|
| |
| |
(5) | (Recovery) |
|----- DNR(1,1)--->| (6)
|<--- DNR(1,1)---->|
| |
| |
| (SF on P(A->Z)) | (7)
(8) |<--- SF-P(0,0)----|
|---- NR(0,0)----->|
| |
| |
| (Recovery) | (9)
|<----- NR(0,0)----|
| |
(1) The protected domain is operating without any defect, and the working entity is used for delivering the normal traffic.
（1）保護されたドメインは問題なく動作しており、正常なトラフィックの配信には現用エンティティが使用されています。
(2) Signal Fail occurs on the working entity in the Z to A direction. Selector and bridge of node A select the protection entity. Node A generates an SF(1,1) message.
（2）ZからA方向の動作エンティティで信号障害が発生します。ノードAのセレクターとブリッジは、保護エンティティを選択します。ノードAはSF（1,1）メッセージを生成します。
(3) Upon receiving SF(1,1), node Z sets selector and bridge to protection entity. As there is no local request in node Z, node Z generates an NR(1,1) message.
（3）SF（1,1）を受信すると、ノードZはセレクタとブリッジを保護エンティティに設定します。ノードZにはローカル要求がないため、ノードZはNR（1,1）メッセージを生成します。
(4) Node A confirms that the far end is also selecting protection entity.
（4）ノードAは、遠端も保護エンティティを選択していることを確認します。
(5) Node A detects clearing of the SF condition and sends a DNR(1,1) message.
（5）ノードAがSF状態のクリアを検出し、DNR（1,1）メッセージを送信します。
(6) Upon receiving DNR(1,1), node Z also generates a DNR(1,1) message.
（6）DNR（1,1）を受信すると、ノードZもDNR（1,1）メッセージを生成します。
(7) Signal Fail occurs on the protection entity in the A to Z direction. Selector and bridge of node Z select the working entity. Node Z generates an SF-P(0,0) message.
（7）信号障害は、AからZ方向の保護エンティティで発生します。ノードZのセレクターとブリッジが作業エンティティを選択します。ノードZは、SF-P（0,0）メッセージを生成します。
(8) Upon receiving SF-P(0,0), node A sets selector and bridge to working entity and generates an NR(0,0) message.
（8）SF-P（0,0）を受信すると、ノードAはセレクターとブリッジを作業エンティティに設定し、NR（0,0）メッセージを生成します。
(9) Node Z detects clearing of the SF condition and sends an NR(0,0) message.
（9）ノードZはSF条件のクリアを検出し、NR（0,0）メッセージを送信します。
Exmaple 5. 1:1 bidirectional protection switching (non-revertive mode) - Bidirectional SF on working followed by bidirectional SF on protection
例5. 1：1双方向保護スイッチング（非リバーティブモード）-動作時の双方向SFと、それに続く保護時の双方向SF
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(A<->Z)) | (2)
(3) |<---- SF(1,1)---->| (3)
| |
| |
(4) | (Recovery) | (4)
(5) |<---- NR(1,1)---->| (5)
|<--- DNR(1,1)---->|
| |
| |
(6) | (SF on P(A<->Z)) | (6)
(7) |<--- SF-P(0,0)--->| (7)
| |
| |
(8) | (Recovery) | (8)
|<---- NR(0,0)---->|
| |
(1) The protected domain is operating without any defect, and the working entity is used for delivering the normal traffic.
（1）保護されたドメインは問題なく動作しており、正常なトラフィックの配信には現用エンティティが使用されています。
(2) Nodes A and Z detect local SF conditions on the working entity, set selector and bridge to protection entity, and generate SF(1,1) messages.
（2）ノードAおよびZは、動作中のエンティティのローカルSF状態を検出し、セレクタとブリッジを保護エンティティに設定し、SF（1,1）メッセージを生成します。
(3) Upon receiving SF(1,1), each node confirms that the far end is also selecting protection entity.
（3）SF（1,1）を受信すると、各ノードは遠端も保護エンティティを選択していることを確認します。
(4) Each node detects clearing of the SF condition and sends an NR(1,1) message as the last received APS message was SF.
（4）最後に受信したAPSメッセージがSFだったため、各ノードはSF状態のクリアを検出し、NR（1,1）メッセージを送信します。
(5) Upon receiving NR(1,1), each node sends DNR(1,1).
（5）NR（1,1）を受信すると、各ノードはDNR（1,1）を送信します。
(6) Signal Fail occurs on the protection entity in both directions. Selector and bridge of each node selects the working entity. Each node generates an SF-P(0,0) message.
（6）信号障害は、保護エンティティで双方向に発生します。各ノードのセレクターとブリッジは、作業エンティティを選択します。各ノードはSF-P（0,0）メッセージを生成します。
(7) Upon receiving SF-P(0,0), each node confirms that the far end is also selecting working entity.
（7）SF-P（0,0）を受信すると、各ノードは遠端も動作エンティティを選択していることを確認します。
(8) Each node detects clearing of the SF condition and sends an NR(0,0) message.
（8）各ノードはSF条件のクリアを検出し、NR（0,0）メッセージを送信します。
Authors' Addresses
著者のアドレス
Huub van Helvoort (editor) Huawei Technologies
Huub van Helvoort（編集者）Huawei Technologies
EMail: huub@van-helvoort.eu
Jeong-dong Ryoo (editor) ETRI
ジョンドンリュウ（編者）ETRI
EMail: ryoo@etri.re.kr
Haiyan Zhang Huawei Technologies
Hは目障りな張胡Aはテクノロジー
EMail: zhanghaiyan@huawei.com
Feng Huang Philips
F鞥Huang Philips
EMail: feng.huang@philips.com
Han Li China Mobile
はん ぃ ちな もびぇ
EMail: lihan@chinamobile.com
Alessandro D'Alessandro Telecom Italia
アレッサンドロダレッサンドロテレコムイタリア
EMail: alessandro.dalessandro@telecomitalia.it