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
        

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および擬似回線エミュレーションエッジツーエッジ(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サバイバルフレームワーク文書(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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者(複数可)材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者(単数または複数)から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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
        
1. Introduction
1. はじめに

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])とスードワイヤため(のPW)([RFC3985 ]と[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サバイバルフレームワーク[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に記載されています。リニア保護は、迅速かつ簡単な保護スイッチングを提供します。それは、ネットワーク内の点の任意の対の間で動作することができるので、メッシュネットワークでは、線形保護は非常に適切な保護機構を提供します。これは、中間ノードの欠陥、スパン、搬送路セグメント、またはエンド・ツー・エンドの搬送経路から保護することができます。

1.1. Protection Architectures
1.1. 保護アーキテクチャ

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.

サバイバルフレームワークドキュメント[RFC6372]に記載されているように、保護スイッチングは、保護ドメインに適用されます。本文書の目的のために、我々は、2つのラベル・エッジ・ルータ(のLER)及びそれらを接続搬送路から成るように、ポイントツーポイントLSPの保護ドメインを定義する(図3参照)。ポイント・ツー・マルチポイントLSPのために、保護ドメインは、ルート(またはソース)LER、宛先(またはシンク)の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 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.

[RFC6372]に提示される1つの+ 1単方向アーキテクチャにおいて、保護搬送路は、作業搬送路に専用されます。通常のトラフィックをブリッジ([RFC4427]で定義されるように)保護ドメインの源に永久ブリッジによって現用と予備パスの両方に供給されます。保護ドメインのシンクは、例えば、所定の基準に基づいて、サーバ障害表示をトラフィックを受信するためにそこから作業又はプロテクションパスのどちらかを選択するセレクタを使用します。 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個のサービスのうち、予備パスを共有することにより、上記1アーキテクチャ:N保護アーキテクチャは、1を拡張します。再び、予備パスは完全にそれを保護するために使用されているN個の作業搬送路のいずれかから割り当てと互いに素れます。各サービスのための通常のデータトラフィックは、そのサービスのための通常の作業経路上、または、保護スイッチングを([RFC6372]に記載されているように)トリガの場合において、保護経路上で送信することができる。いずれかの送信されますセレクタは、ソースで使用される場合1:スイッチング動作は1と同様です。複数の現用パスサービスは、保護切り替えを引き起こした場合には、彼らのサービスレベル契約(SLA)に依存して、いくつかのサービスは、保護経路上の限られた資源の結果として送信されないことに留意すべきです。このアーキテクチャでは、保護スイッチングの調整のためのリソース割り当て交渉の必要があるかもしれません。このための手順は、今後の検討課題であると将来の文書に対処することができます。

1.2. Scope of the Document
1.2. 文書の範囲

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.

サバイバルフレームワーク[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](特に、要求63-65及び74-79)によって必要とされると[RFC6372]に記載されているように、プロトコルは、MPLS-TPネットワークにおけるLSPの保護に対処します。基本的なプロトコルは、組み合わせて使用​​するために設計されています

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保護アーキテクチャは、協調プロトコルの使用を必要としないが、プロトコルは、スイッチング状態が発生した遠側エンドポイントに通知しての一貫性を検証するために、パスの入口ノードによって使用されてもよいですエンドポイントの設定。この使用は、[RFC5654]の定義による単方向でポイントツーマルチポイント搬送路、のために特に有用であり得ます。ポイント・ツー・マルチポイントパスのこのプロトコルの使用は、この文書の範囲外であり、将来の適用文書に対処することができます。

2. Conventions Used in This Document
この文書で使用される2.表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2.1. Acronyms
2.1. 略語

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

ルータMEGの切り替え保護LSRラベルのCTチャネルタイプDNR DO-ない-戻すFS強制スイッチG-AChのジェネリック関連するチャンネルLERラベルエッジルータLOロックアウトは、MPLS MS手動スイッチNRないためのエンティティグループMEP MEGエンドポイントMPLS-TPトランスポートプロファイルを管理しましたプロバイダーエッジSD信号劣化SF信号障害SFCクリア信号障害SLAサービス・レベル・アグリーメントを切替要求OAM運用、管理、およびメンテナンスPSC保護状態協調プロトコルS-PE

T-PE Terminating Provider Edge WTR Wait-to-Restore

T-PE終端プロバイダーエッジWTR復元待ち

2.2. Definitions and Terminology
2.2. 定義と用語

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に適合されています。加えて、我々はそれがLSR、LER、T-PEまたはS-PEであるかどうか、MPLS-TPネットワーク要素を指すために、用語 "LER" を使用します。

3. Protection State Control Logic
3.保護状態制御ロジック

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.

保護スイッチングは、一緒になって、遠端LERから受信した入力と[RFC5654]の要件74-79に記載のローカルトリガーを処理します。 1保護または1のいずれかのトラフィックを受信するセレクタを切り替える:1または1 + 1保護これらの入力に基づいて、LERは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、サーバ層、外部のオペレータコマンド、ローカル制御プレーン(存在する場合)、および待ちツー復元タイマからのトリガを受け付けます。これらのローカル要求元のすべてを考慮することにより、それが最も高い優先度のローカル要求を決定します。この優先度の高い要求が遠端LERから受信した情報を使用してこの地域の要求をクロスチェックすることが、PSC制御ロジックに渡されます。 PSC制御ロジックは、例えば、アクションが取られるために必要なものを判断するためにLERのローカルアクションを、この入力を使用して、または遠端LERに送信されるべきメッセージ、および保護ドメインの現在の状態。

3.1. Local Request Logic
3.1. ローカルリクエストロジック

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上のローカル管理コマンドを発行することができます。コマンドクリア、保護のロックアウトを強制スイッチ、手動スイッチ、(強制切替、手動切替、消去、および復旧LSP /スパンのロックアウトとして[RFC4427]で定義さは、それぞれ)をサポートしなければなりません。実装は、オペレータ用の追加コマンドを提供してもよい(MAY)。これらのコマンドは、任意の二つの実装の間で互換性のない行動を導入していないことを提供し、彼らはこの文書の範囲外です。例えば、実装は、手動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コントロールプレーンの表示 - ネットワーク(シグナリングまたはルーティングのいずれか)に能動制御プレーンが存在する場合、それは、制御プレーンによって検出された条件に基づいて、保護スイッチングをトリガすることができます。制御プレーンは、GMPLS [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信号劣化(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.

クリア信号失敗(SFC)O - サーバ層、コントロールプレーン、または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) - オペレータは、トラフィックは保護パスに現用パスのいずれかから切り替えることを要求した場合。

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.

入力ソースのいずれも、任意のトリガーを発生しなかった場合は、[ローカル要求論理は、現在のローカル要求として無要求(NR)を生成してはなりません。

3.2. Remote Requests
3.2. リモート要求

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制御ロジックは搬送路の遠端LERからPSCメッセージを受け付けるものと示されました。 Remoteメッセージは、遠端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.

リモートLO O - リモートエンドポイントが原因保護オペレータコマンドのロックアウトに使用不可状態であることを示しています。

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.

リモートSF O - リモートエンドポイントは、保護ドメインにおける搬送路のいずれかに信号障害状態を検出したことを示します。このリモートメッセージは、搬送経路は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.

リモートSD○ - リモートエンドポイントは保護ドメインにおける搬送路の一方に信号劣化状態を検出したことを示しています。このリモートメッセージは、搬送路を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.

リモート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.

リモートMS O - リモートエンドポイントは、プロテクションパスに現用パスからのトラフィックを切り替えるためにオペレータコマンドの下で動作していることを示しています。

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.

リモートWTR O - リモートエンドポイントは、障害状態が回復し、正常な状態に戻すための準備として、その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.

リモートNR○ - リモートエンドポイントは、報告する異常な状態を持っていないことを示しています。

3.3. PSC Control Logic
3.3. PSC制御ロジック

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制御論理によって保持されます。

3.4. PSC Message Generator
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で説明したようにメッセージが送信されます。

3.5. Wait-to-Restore (WTR) Timer
3.5. 復元待ち(WTR)タイマ

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 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.

WTRタイマは、現用パスに障害状態から回復し、保護ドメインは、リバーティブ動作用に設定されている場合、通常状態への復帰を遅延させるために使用されます。タイマーの長さは、オペレータによってプロビジョニングすることができます。 WTRは、2つの状態のいずれであってもよい:実行中または停止します。 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タイマーが実行されている場合は、停止コマンドを送信すると、タイマーをリセットし、停止状態にWTRタイマーを置くが、WTRは、ローカル信号を生成する有効期限ないものとしないものとします。 WTRタイマーが停止している場合は、停止コマンドは無視されなければなりません。

3.6. PSC Control States
3.6. PSCコントロールの状態

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によって維持されています。状態情報は、保護ドメインの現在の状態の情報、現在の状態の原因の指示(例えば、局部LOコマンドに利用できない、遠隔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ノーマル状態 - 保護及び現用パスの両方が完全に割り当てられ、アクティブされ、データトラフィックは、上搬送(またはから選択)されている現用パス、およびNOトリガ・イベントがドメイン内で報告されていません。

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 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状態を行うには、-戻らない - 保護ドメインが保護状態から回復しましたが、オペレータは自動的に回復すると通常の状態に戻すことはない保護ドメインを設定しています。オペレータは通常の状態に戻すには、このコマンドを発行するか、別の状態に切り替えるための新しいトリガがあるまで保護ドメインは、この状態のままものとします。

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を参照してください。

3.6.1. Local and Remote State
3.6.1. ローカルとリモートの状態

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制御ロジックは、現在の保護ドメインの状態と一緒に、これは、このLERのために、ローカルまたはリモート状態であるか否かの指示を維持しなければなりません。

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メッセージを送信するリモート利用不可状態であろう。

4. Protection State Coordination (PSC) Protocol
4.保護状態調整(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 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.

双方向の保護スイッチング、ならびに一方向1:1保護は、二つの可能な経路、現用または保護パスを、任意の所与の状況でデータトラフィックを送信しているかを決定する二つのエンドポイント間の調整を必要とします。第3節で説明したように保護スイッチングがトリガされると、エンドポイントは協調様式で他の1本のパスから切り替えの相互に通知しなければなりません。

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.

プロトコルを調整するタイプごとに異なる可能性があります。一つの可能​​性は、保護スイッチングを開始しているLERがスイッチを示すプロトコルメッセージを送信するが、実際の切り替えのみ遠端LERからACKを受信した後に行われる二段階的コーディネーションです。他の可能性は、開始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つのエンドポイント間で使用されるプロトコルメッセージについて説明します。

4.1. Transmission and Acceptance of PSC Control Packets
4.1. PSC制御パケットの送信と受け入れ

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つの迅速なメッセージを送るべきです。しかし、正常な状態にWTR状態からLER転送遠隔NRメッセージの結果として、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 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.

3つの迅速なメッセージのデフォルトの頻度、ならびに継続的なメッセージ送信のデフォルトの周波数の両方は、オペレータによって設定されなければなりません。使用される実際の周波数は、個々の保護されたLSPのために、確立時に、構成可能です。管理目的のために、オペレータは、特定のLSPの現在のデフォルト周波数値だけでなく、実際の値を取得することができるべきです。 50ミリ秒以内に切り替え保護のために、最初の3つの迅速なPSCのメッセージのデフォルト間隔は、もはや3.3ミリ秒以下にすることが推奨されていません。この周波数を使用して、遠端が50ミリ秒以内にスイッチング動作のトリガ10ミリ秒以内に表示し、完了を受信することが保証されることを可能にします。後続のメッセージは、継続的に5秒のデフォルト間隔で送信されるべきである(SHOULD)。継続的なメッセージの目的は、PSCセッションがまだ生きていることを確認することです。

If no valid PSC message is received, over a period of several continual messages intervals, the last valid received message remains applicable.

有効なPSCメッセージが受信されない場合は、いくつかの継続的なメッセージインターバルの期間にわたって、最後の有効な受信したメッセージには、該当のまま。

4.2. Protocol Format
4.2. プロトコルフォーマット

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 Reserved1とReserved2両方のフィールドは0に設定し、受信時に無視しなければなりません。

o The following subsections describe the remaining fields of the PSC payload.

以下のサブセクションoをPSCペイロードの残りのフィールドを記述する。

4.2.1. PSC Ver Field
4.2.1. PSCビューフィールド

The Ver field identifies the version of the protocol. For this version of the document, the value SHALL be 1.

版フィールドは、プロトコルのバージョンを識別する。ドキュメントのこのバージョンでは、値は1でなければなりません。

4.2.2. PSC Request Field
4.2.2. PSC要求フィールド

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.

保護の(14)ロックアウトO - エンドポイントは、管理コマンドの結果として、保護パスを無効にしたことを示しています。 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フィールドは、現用パス(すなわち、FPATHが1に設定される)ブロックされている、およびPathフィールドは、ユーザデータトラフィックがプロテクションパス(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).

(10)信号失敗O - は、送信エンドポイントが信号を識別した作業や予備パスのいずれかで条件を失敗することを示しています。 、およびデータトラフィックがどこにあるPathフィールドが表示しなければならない。FPATHフィールドは、(現用パスなら、FPATHは1に設定されている、すなわち、保護経路た場合、その後、FPATHが0に設定されている)、障害の状況をレポートするパスを識別しなければなりません(プロテクションパスがブロックされている場合、すなわち、そのパスが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フィールドは、現用パス(すなわち、FPATHが1に設定される)ブロックされている、およびPathフィールドは、ユーザデータトラフィックがプロテクションパス(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-未復帰は、 - 送信エンドポイントが障害/閉塞状態から回復したことを示しているが、局部設定に、保護ドメインは、それが保護しているかのようにデータを転送し続けることが要求されています状態、正常な状態に戻すのではなく。 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によって管理される)と、受信時に無視されなければなりません。

4.2.3. Protection Type (PT) Field
4.2.3. 保護タイプ(PT)フィールド

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保護アーキテクチャは、ATセレクタブリッジの使用によって特徴付けられますソースノード。

4.2.4. Revertive (R) Field
4.2.4. 復元(R)フィールド

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: o 0 - non-revertive mode

このフィールドは、送信エンドポイントは、リバーティブモードで動作するように構成されていることを示しています。二つの端点間の矛盾がある場合、すなわち、一方の端点は、復元動作のために構成されており、第二のエンドポイントは、管理システムが通知すべき、非復帰モードです。次の可能な値は次のとおりです。0 O - 非リバーティブモード

o 1 - revertive mode

1 - リバーティブモード

4.2.5. Fault Path (FPath) Field
4.2.5. 障害パス(FPATH)フィールド

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

0:異常状態が保護パス上にあることを示し、

o 1: indicates that the anomaly condition is on the working path

1○:異常状態が現用パス上にあることを示し

o 2-255: for future extensions and SHALL be ignored by this version of the protocol.

2-255 O:将来の拡張のために、プロトコルのこのバージョンによって無視されなければなりません。

4.2.6. Data Path (Path) Field
4.2.6. データパス(パス)フィールド

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:

Pathフィールドには、保護パス上で搬送されているデータを示しています。通常の条件下では、保護経路は、(特に、1:1または1:Nアーキテクチャ)すべてのユーザ・データ・トラフィックを伝送する必要はありません。障害が発生した場合は/ワーキングパスのデータトラフィックが保護パス上で転送されます、その、現用パスのいずれかに条件を劣化させます。以下は、可能な値は次のとおりです。

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).

0 O:(:Nアーキテクチャ1)または(1つの+ 1アーキテクチャでは)冗長ユーザデータトラフィックを搬送する予備パスは、ユーザデータトラフィックを搬送されていないことを示しています。

o 1: indicates that the protection path is transmitting user traffic replacing the use of the working path.

1 O:保護パスが現用パスの使用を交換するユーザトラフィックを送信していることを示しています。

o 2-255: for future extensions and SHALL be ignored by this version of the protocol.

2-255 O:将来の拡張のために、プロトコルのこのバージョンによって無視されなければなりません。

4.2.7. Additional TLV Information
4.2.7. 追加TLV情報

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ユニットはありません。

4.3. Principles of Operation
4.3. 動作の原理

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:保護ドメイン

4.3.1. Basic Operation
4.3.1. 基本操作

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フィールドの値は、二つのエンドポイント間で同一でなくてもよいです。特に、リモートメッセージは、エンドポイントは、それがパスのフィールドに影響を与えない間(以下のサブセクションで詳細)送信される要求フィールドを変化させなくてもよいことに留意すべきです。

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 LER一の搬送路一方からのデータを選択/輸送することができる場合、単一段階的プロトコルを使用しての副作用として、片側のトリガー(例えば、オペレータコマンドまたは一方向SF)の状態遷移の間の短い期間が存在することになります他のエンドポイントは、他の搬送経路から選択/輸送されます。リモートメッセージが受信され、遠端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は、Pathフィールドの値です。全ての実施例は、単一の現用パスと(図3に示されるように)単一の予備パスとLER-AおよびLER-Zとの間の保護ドメインをとります。 1保護データトラフィックは保護またはワーキングパスのいずれかのみに送信されます。:やはり、1を使用するときにことに留意すべきです1つの+ 1保護を使用する場合に対し、トラフィックが両方のパス上で送信され、受信LER状態に基づいて適切な信号を選択すべきです。テキストは、データトラフィックの「輸送」として、この送信/選択を参照します。 1つの+ 1単方向保護のため、セレクタの状態は、ローカルメッセージに反応して切り替えられます。リモートメッセージ、1 + 1単方向保護するように構成されているLERを受信した場合、新しいリモート状態に転送します。しかし、それは、最新の既知のローカル状態に応じてデータを選択していきます。 LERが正常な状態に遷移すると、PSC制御プロセスは、それが新しい状態への移行を進めるべきかどうかを決定するために、ローカルのトリガの永続的な状態をチェックしなければなりません。

4.3.2. Priority of Inputs
4.3.2. 入力の優先順位

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.クリア(オペレータコマンド)
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)
ワーキング(OAM /制御プレーン/サーバー表示)5.信号障害

6. Signal Degrade on working (OAM / control-plane / server indication)

ワーキング(OAM /制御プレーン/サーバー表示)6.信号劣化

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つの入力のより高い優先順位。

4.3.3. Operation of PSC States
4.3.3. PSC国の運用

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からPSCメッセージのいずれか - 状態ごとに、我々は、反応、すなわち、新しい状態及び各可能な入力に、送信するメッセージを定義します。保護ドメインの新しい状態は、状態を報告しているLERの観点から記述されていることに留意すべきです。そのため、「LERは状態になり」の語は、保護ドメインは、この新しい状態にあることを報告LERを参照しています。定義状態がメッセージを「無視」する場合は、その意図は、現在のPSCメッセージ保護ドメインが現在の状態で残っているものとし、(4.1節で提示される)LERを送信し続けるべきことです。

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メッセージを受信した場合LERが正常であるかのようにリモートFS(1,1)メッセージを受信した状態は、その後、PSC制御ロジックは、全ての入力(ローカル入力とリモートメッセージの両方)を再評価SHALL。

4.3.3.1. Normal State
4.3.3.1。通常の状態

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.

保護ドメインが有効に特別な条件を持っていない場合には、入口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:

通常の状態では、リモートのメッセージは、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.

NR(0,0)メッセージを送信するために継続したまま、o保護メッセージのリモートロックアウトは、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他のすべてのリモートメッセージは無視されなければなりません。

4.3.3.2. Unavailable State
4.3.3.2。使用不可の状態

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: 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.

LERは(LER-Aを想定)使用不可状態にある場合、次の遷移は、ローカル入力への反応に関連している:LERがリモート使用不可状態にある場合、ローカルクリア入力は無視される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がローカル使用不可状態のままと遠端LER(LER-Z)と(0,0)メッセージLOを送信せなければなりません。

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が正常な状態に移動せなければなりません。 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の状態が解消されるまでによる予備パス(即ち、起因SF条件に)が利用できないこのFSが遠端によって受信されなくてもよいことに留意すべきです。

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に起因する)予備パス入力にローカル信号失敗LERがローカル使用不可状態のままとSF(0,0)メッセージを送信するようにさせなければなりません。

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他のすべてのリモートメッセージは無視されなければなりません。

4.3.3.3. Protecting Administrative State
4.3.3.3。管理状態を守ります

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との間の差は、ローカルインジケータが受信されても​​よいものに影響 - SFローカルMSをオーバーライドすることになるのに対し、ローカル要求論理は、ローカルFSの影響を受けたときに任意のローカルSFをブロックします。一般的に、MSは、ローカルまたはリモートのSF又はLO状態の場合にはキャンセルされます。

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)メッセージの送信を開始せなければなりません。 LERは、FSの状況による管理状態を保護する(ローカルまたはリモート)である場合には、保護上の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現用パス上のローカル信号障害の徴候は、LERは、ローカルの保護障害状態に入ると、現在の状態は、(ローカルまたはリモート)手動切り替えオペレータコマンドによるものであれば、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 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.

アクティブなローカル強制スイッチオペレータコマンドがある場合、O遠隔強制切り替えメッセージはPSCプロセスロジックによって無視されます。保護管理状態を遠隔強制切り替えメッセージが原因である場合、LERは、リモートの保護管理状態のままにして最後のメッセージを送信し続けるものとします。保護管理状態は、ローカルまたはリモートの手動スイッチのいずれかが原因である場合には、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.

ローカル保護管理状態であれば、リモートDNR O(0,1)メッセージは無視されます。リモート保護管理状態にある場合には、LERは状態を-戻らないと、現在のメッセージの送信を継続して行きましょう。

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.

ローカル保護管理状態であれば、リモートNR(0,0)Oメッセージは無視されます。リモート保護管理状態にあるとアクティブなローカル信号障害の兆候がない場合、LERは、通常の状態に移動し、NR(0,0)メッセージを送信し始めるものとします。ローカル信号障害が現用パスに存在する場合、LERは、ローカルの保護障害状態に移動して、SF(1,1)メッセージを送信し始めるものとします。

o All other remote messages SHALL be ignored.

O他のすべてのリモートメッセージは無視されなければなりません。

4.3.3.4. Protecting Failure State
4.3.3.4。障害状態の保護

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.

保護パスに輸送されるものとします。 LERがこの状態にあるときに、それがいずれかのローカル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で非リバーティブ動作用に設定されている場合、この入力は状態を-ない-戻すんし、DNR(0,1)メッセージの送信を開始へ行くためにLERをせなければなりません。

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, 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 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がリモートの保護管理状態に入り、そして地元の保護、障害状態であれば、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リモート障害状態を保護する場合は、リモートDO-ない-戻すメッセージは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)は、LERが正常な状態に移動せなければなりません。

o All other remote messages SHALL be ignored.

O他のすべてのリモートメッセージは無視されなければなりません。

4.3.3.5. Wait-to-Restore State
4.3.3.5。復元待ち状態

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.

現用パスに障害状態から回復すると、復元待ち状態が回復し、障害を安定させるためにWTRタイマーの期間、通常の状態に戻す遅らせるために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保護命令のローカルロックアウトは、ローカル使用不可状態になり、そしてLO(0,0)メッセージの送信を開始し、WTRタイマーに停止コマンドを送信しなければなりません。

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ローカル強制切り替えコマンドは、ローカルの保護管理状態に入り、およびFS(1,1)メッセージの送信を開始し、WTRタイマーに停止コマンドを送信しなければなりません。

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保護メッセージのリモートロックアウトは、リモート利用できない状態になり、及びNR(0,0)メッセージの送信を開始し、WTRタイマーに停止コマンドを送信しなければなりません。

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リモート強制切り替えメッセージは、リモート管理状態を守るに行き、NR(0,1)メッセージの送信を開始し、WTRタイマーに停止コマンドを送信しなければなりません。

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保護パスのためのリモート信号障害メッセージは、リモート利用できない状態になり、及びNR(0,0)メッセージの送信を開始し、WTRタイマーに停止コマンドを送信しなければなりません。

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リモート手動切り替えメッセージは、リモート管理状態を守るに行き、NR(0,1)メッセージの送信を開始し、WTRタイマーに停止コマンドを送信しなければなりません。

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.

WTRタイマーが実行されている場合は、O、リモートNRメッセージは無視されます。 WTRタイマーが停止している場合は、リモートNRメッセージには、LERが正常な状態に入るせなければなりません。

o All other remote messages SHALL be ignored.

O他のすべてのリモートメッセージは無視されなければなりません。

4.3.3.6. Do-not-Revert State
4.3.3.6。ドゥーない、元に戻す状態

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-ない-復帰状態にある間、管理者が正常な状態に戻すには、このコマンドを送信するまで、データトラフィックは保護パスに輸送することが継続するものとします。それがこの状態とノーマルとの間には根本的な違いがあることに留意すべきである - ノーマル状態の強制切り替えが実際に状態を行うには、ない-戻すには、搬送経路のスイッチを使用する原因となるのに対し、強制スイッチだけに(状態を切り替えます管理状態を守る)が、トラフィックは保護パス上で輸送され続けるだろう!通常の状態に戻すには、管理者がクリアコマンドに続いて保護コマンドのロックアウトを発行しなければなりません。

When in Do-not-Revert state, the following describe the reaction to local input:

DO-ない - 元に戻す状態で、地元の入力に対する反応を説明し、次の場合には:

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-ない-戻し状態で、次は、リモートのメッセージに対する反応を記述する場合:

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他のすべてのリモートメッセージは無視されなければなりません。

5. IANA Considerations
5. IANAの考慮事項
5.1. Pseudowire Associated Channel Type
5.1. 擬似回線関連するチャネルタイプ

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)
        
5.2. PSC Request Field
5.2. PSC要求フィールド

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)運用、管理、および管理(OAM)パラメータ」レジストリは、「MPLS PSC要求レジストリ」と呼ばれる。ました[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
        
5.3. Additional TLVs
5.3. 追加のTLV

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)運用、管理、および管理(OAM)パラメータ」レジストリは「MPLS PSC TLVレジストリ」と呼ばれます。 [RFC5226]で指定されるように、このレジストリ内のすべてのコードポイントは、「IETFレビュー」の手順に従って割り当てられなければなりません。

6. Security Considerations
6.セキュリティの考慮事項

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]で定義された関連するチャネルの一般化です。したがって、このドキュメントはこれら二つの文書に関連するチャネルのために提供し説明したセキュリティ・メカニズムに大きく依存しています。

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であり、これらのフィールドへの変更は、ピアエンドポイントの動作を変更すると同じようにパスフィールド。この文書は保護状態の変化を示すメッセージを受信すると、ネットワークの挙動の変化を回避する方法を定義していませんが、状態間の遷移は、現実と一致しないメッセージの顔で知られており、安定した行動に収束します。

7. Acknowledgements
7.謝辞

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でのMPLSの相互運用性設計チーム、およびITU-TでT-MPLSアドホックグループ)のすべてのメンバーに感謝したいと思います。

8. Contributing Authors
8.共著

Hao Long Huawei Technologies Co., Ltd. F3 Building, Huawei Industrial Park Bantian, Shenzhen, China

H AO長いHU Aは、Sは、中国の真の工業団地の禁止のための技術CO。、株式会社F3の建物、HU日です

EMail: longhao@huawei.com

メールアドレス:longhao@huawei.com

Davide Chiara Ericsson Via Calda 5, 16152 Genova Italy

デビッド・クレアエリクソン経由ホット5、16152ジェノヴァ、イタリア

EMail: davide.chiara@ericsson.com

メールアドレス:davide.chiara@ericsson.com

Dan Frost Cisco Systems

ダンフロストシスコシステムズ

EMail: danfrost@cisco.com

メールアドレス:danfrost@cisco.com

Francesco Fondelli Ericsson via Moruzzi 1 56100, Pisa Italy

Moruzzi 1 56100、ピサイタリア経由フランチェスコFondelliエリクソン

EMail: francesco.fondelli@ericsson.com

メールアドレス:francesco.fondelli@ericsson.com

9. References
9.参考文献
9.1. Normative References
9.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[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]ボッチ、M.、Vigoureux、M.、およびS.ブライアント、 "MPLSジェネリック関連チャンネル"、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]ニーヴン、ジェンキンス、B.、Brungard、D.、ベッツ、M.、Sprecher、N.、およびS.上野、 "MPLSトランスポートプロファイルの要件"、RFC 5654、2009年9月。

9.2. Informative References
9.2. 参考文献

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。

[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC3945]マニー、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]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで(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]マニー、E.およびD. Papadimitriou、RFC 4427、2006月 "一般化マルチプロトコルラベルスイッチング(GMPLS)の回復(保護と回復)用語"。

[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]ラング、J.、Rekhter、Y.、およびD. Papadimitriou、 "RSVP-TE拡張エンドツーエンド一般化マルチプロトコルラベルスイッチング(GMPLS)回復のサポートで"、RFC 4872、2007年5月。

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.

[RFC4873]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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]ナドー、T.とC. Pignataro、 "Pseudowireの仮想回線接続性検証(VCCV):スードワイヤ用制御チャネル"、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]ボッチ、M.とS.ブライアント、「マルチセグメント擬似回線エミュレーションエッジツーエッジのためのアーキテクチャ」、RFC 5659、2009年10月。

[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[RFC5920]牙、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]ボッチ、M.、ブライアント、S.、フロスト、D.、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、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.、エド。およびA.ファレル、エド。、 "MPLSトランスポートプロファイル(MPLS-TP)耐障害フレームワーク"、RFC 6372、2011年9月。

Appendix A. PSC State Machine Tables

付録A. PSCステートマシンテーブル

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つの遠隔入力(状態マシンを実行する1つ以上の他のノードから来る入力)を示します。

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

Nノーマル状態UA:LO:L利用不可状態によるローカルロックアウトUAに:P:保護パスUAに起因ローカルSFにL利用不可状態:LO:による保護メッセージUAの遠隔ロックアウトに使用不可状態をR:P:Rにより使用不可状態W::Lは、現用パスPFに起因する局所的なSFに障害状態の保護:W:F:Rが原因現用パスPA上のリモートSFメッセージに障害状態の保護Lが原因ローカルFSに管理状態を保護する保護パスPF上のリモートSFメッセージへオペレータコマンドPA:M:原因ローカルMSのオペレータコマンドPAへの管理状態を守るL:F:M:Rが原因リモートMSメッセージWTRが復元待ち状態DNRに管理状態を守るRが原因リモートFSメッセージPAへの管理状態を守ります状態を-戻りません

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.

各状態は、Request、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現用パス上の要求なし保護パスSF-W信号障害の保護SF-P信号障害のOCオペレータクリアLOロックアウトは、強制スイッチSFCクリア信号障害MS手動スイッチWTRExp WTRは期限切れしないFS

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メッセージMSリモートMSメッセージWTR遠隔WTRメッセージDNR遠隔DNRメッセージNR遠隔NRメッセージをFS

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:Remoteメッセージステートマシン

               | 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]は、現在の状態のままである(:LO:UA R)及びSF(0,0)を送信します。

[2] Remain in the current state (UA:LO:R) and transmit SF(1,0).

[2]は、現在の状態のままである(:LO:UA R)及びSF(1,0)を送信します。

[3] Remain in the current state (UA:P:R) and transmit SF(1,0).

(:P:UA R)[3]現在の状態のままとSF(1,0)を送信します。

[4] Remain in the current state (PA:F:R) and transmit SF(1,1).

(R:F PA)及びSF(1,1)を送信する[4]現在の状態のままです。

[5] If the SF being cleared is SF-P, transition to N. If it's SF-W, ignore the clear.

それは、SF-Wです明らかに無視する場合は、[5] SFがクリアされている場合はSF-P、N.への移行があります。

[6] Remain in current state (UA:x:R), if the SFc corresponds to a previous SF, then begin transmitting NR(0,0).

[6]現在の状態に留まる(UA:X:R)、SFCは前のSFに対応する場合、その後、NR(0,0)の送信を開始します。

[7] If domain configured for revertive behavior transition to WTR, else transition to DNR.

[7]ドメインはWTR、DNRの他の遷移にリバーティブ動作遷移のために設定した場合。

[8] Remain in PA:F:R and transmit NR(0,1).

R及びNR(0,1)を送信する:F:[8] PAに残ります。

[9] Remain in WTR, send NR(0,1).

[9] NR(0,1)を送信、WTRに残ります。

[10] Transition to UA:LO:R continue sending SF(0,0).

UAに[10]遷移: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.

WTR状態への[14]の移行とは、現在のメッセージを送信し続けます。

[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.

ローカル入力がSF-Pの場合[16]、その後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.

ローカル入力はSF-Wである場合[17]、その後、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及びSF(0,1)を送信します。

Appendix B. Exercising the Protection Domain

保護ドメインを行使付録B.

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機能の動作を組み合わせることにより、この操作を行うことができます。その一つの可能​​な組み合わせは、保護動作のロックアウトを発行して、保護パスの診断テストのためのOAM機能を使用することです。同様に、現用パスがアクティブでない場合にパスをテストするためには、保護に強制切り替えを行う関与し、次に作業や予備パスのいずれかで診断機能を実行することになります。

Authors' Addresses

著者のアドレス

Yaacov Weingarten (editor) Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel

YaakovのVegarten(編集)、ノキアシーメンスネットワークス3 HnagrセントネーヴNe'emn BホッドHsron 45241イスラエル

EMail: yaacov.weingarten@nsn.com

メールアドレス:yaacov.weingarten@nsn.com

Stewart Bryant Cisco United Kingdom

スチュワートブライアントシスコイギリス

EMail: stbryant@cisco.com

メールアドレス:stbryant@cisco.com

Eric Osborne Cisco United States

エリック・オズボーンシスコ米国

EMail: eosborne@cisco.com

メールアドレス:eosborne@cisco.com

Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel

Nuritのスポークスマンノキアシーメンスネットワークス3 HanagarセントネベNe'emanホッドHasharon 45241イスラエルB

EMail: nurit.sprecher@nsn.com

メールアドレス:nurit.sprecher@nsn.com

Annamaria Fulignoli (editor) Ericsson Via Moruzzi Pisa 56100 Italy

Annamaria Fulignoli(エディタ)エリクソン経由Moruzzi 56100ピサイタリア

EMail: annamaria.fulignoli@ericsson.com

メールアドレス:annamaria.fulignoli@ericsson.com