[要約] RFC 7324は、MPLS Transport Profile（MPLS-TP）の線形保護に関するアップデートを提供しています。その目的は、MPLS-TPネットワークでの信頼性と回復性を向上させることです。
Internet Engineering Task Force (IETF) E. Osborne
Request for Comments: 7324 July 2014
Updates: 6378
Category: Standards Track
ISSN: 2070-1721
Updates to MPLS Transport Profile Linear Protection
MPLSトランスポートプロファイル線形保護の更新
Abstract
概要
This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.
このドキュメントには、RFC 6378の「MPLSトランスポートプロファイル（MPLS-TP）線形保護」で定義されている保護状態調整（PSC）ロジックに対するいくつかの更新が含まれています。これらの更新は、PSCでのTLVの使用に関するいくつかのルールと推奨事項を提供し、ITU-T連絡ステートメントで発生したいくつかの問題に対処し、RFC 6378で十分に説明されていない場合のPSCの動作を明確にします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7324.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7324で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Message Formatting and Error Handling . . . . . . . . . . . . 3
2.1. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . 3
2.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Malformed Messages . . . . . . . . . . . . . . . . . 4
2.2.2. Well-Formed but Unknown or Unexpected TLV . . . . . . 4
3. Incorrect Local Status after Failure . . . . . . . . . . . . 5
4. Handling a Capabilities Mismatch . . . . . . . . . . . . . . 5
4.1. Protection Type Mismatch . . . . . . . . . . . . . . . . 5
4.2. R Mismatch . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Unsupported Modes . . . . . . . . . . . . . . . . . . . . 6
5. Reversion Deadlock Due to a Race Condition . . . . . . . . . 7
6. Clarifying PSC's Behavior in the Face of Multiple Inputs . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
This document contains a number of updates to PSC [RFC6378]. One provides some rules and recommendations around the use of TLVs in PSC. Three of the updates address issues #2, #7, and #8 as identified in the ITU's liaison statement "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks" [LIAISON]. Another clears up a behavior that was not well explained in RFC 6378. These updates are not changes to the protocol's packet format or to PSC's design; they are corrections and clarifications to specific aspects of the protocol's procedures. This document does not introduce backward compatibility issues with implementations of RFC 6378.
このドキュメントには、PSC [RFC6378]に対するいくつかの更新が含まれています。 1つは、PSCでのTLVの使用に関するいくつかのルールと推奨事項を提供します。 3つのアップデートは、ITUの連絡声明「勧告ITU-T G.8131 / Y.1382リビジョン-MPLS-TPネットワークの線形保護スイッチング」[LIAISON]で特定された問題＃2、＃7、および＃8に対処します。もう1つは、RFC 6378で十分に説明されていない動作をクリアします。これらの更新は、プロトコルのパケット形式やPSCの設計に対する変更ではありません。これらは、プロトコルの手順の特定の側面に対する修正と明確化です。このドキュメントでは、RFC 6378の実装に関する下位互換性の問題は紹介していません。
It should be noted that [RFC7271] contains protocol mechanisms for an alternate mode of operating MPLS-TP PSC. Those modes are built on the message structures and procedures of [RFC6378], and so, while this document does not update [RFC7271], it has an impact on that work through its update to [RFC6378].
[RFC7271]には、MPLS-TP PSCを操作する代替モードのプロトコルメカニズムが含まれていることに注意してください。これらのモードは[RFC6378]のメッセージ構造と手順に基づいて構築されているため、このドキュメントは[RFC7271]を更新しませんが、[RFC6378]への更新を通じてその動作に影響を与えます。
This document assumes familiarity with RFC 6378 and its terms, conventions, and acronyms. Any term used in this document but not defined herein can be found in RFC 6378. In particular, this document shares the acronyms defined in Section 2.1 of RFC 6378.
このドキュメントは、RFC 6378とその用語、規則、および頭字語に精通していることを前提としています。このドキュメントで使用されているが、ここでは定義されていない用語は、RFC 6378で見つけることができます。特に、このドキュメントは、RFC 6378のセクション2.1で定義されている頭字語を共有しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section covers message formatting as well as some recommended error checking.
このセクションでは、メッセージのフォーマットと推奨されるエラーチェックについて説明します。
[RFC6378] provides the capability to carry TLVs in the PSC messages. All fields are encoded in network byte order. Each TLV contains three fields, as follows:
[RFC6378]は、PSCメッセージでTLVを伝送する機能を提供します。すべてのフィールドは、ネットワークバイトオーダーでエンコードされます。各TLVには、次の3つのフィールドがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type field (T):
タイプフィールド（T）：
A two-octet field that encodes a type value. The type values are recorded in the IANA registry "MPLS PSC TLV Registry".
タイプ値をエンコードする2オクテットのフィールド。タイプ値は、IANAレジストリ「MPLS PSC TLVレジストリ」に記録されます。
Length field (L):
長さフィールド（L）：
A two-octet field that encodes the length in octets of the Value field. The value of this field MUST be a multiple of 4.
Valueフィールドの長さをオクテットでエンコードする2オクテットフィールド。このフィールドの値は4の倍数でなければなりません。
Value field (V):
値フィールド（V）：
The payload of the TLV. The length of this field (which is the value of the Length field) MUST be a multiple of 4 octets, and so this field may contain explicit padding. The length of each single TLV is the sum of the lengths of its three fields: the length of the value field + 4. The overall TLV Length field in the PSC message contains the total length of all TLVs in octets.
TLVのペイロード。このフィールドの長さ（Lengthフィールドの値）は4オクテットの倍数である必要があるため、このフィールドには明示的なパディングが含まれる場合があります。各単一TLVの長さは、3つのフィールドの長さの合計です。値フィールドの長さ+4。PSCメッセージの全体的なTLV長フィールドには、オクテットのすべてのTLVの全長が含まれます。
It is recommended to implement error and bounds checking to ensure that received messages, if improperly formatted, are handled in such a way to minimize the impact of this formatting on the behavior of the network and its devices. This section covers two such areas -- malformed messages and well-formed but unexpected TLVs.
エラーと境界のチェックを実装して、受信したメッセージが不適切にフォーマットされている場合に、ネットワークとそのデバイスの動作に対するこのフォーマットの影響を最小限に抑えるような方法で処理されるようにすることをお勧めします。このセクションでは、このような2つの領域について説明します。形式が正しくないメッセージと、整形式だが予期しないTLVです。
This text is not intended to limit the error or bounds checking a device performs. The recommendations herein should be taken as a starting point.
このテキストは、デバイスが実行するエラーまたは境界チェックを制限することを意図していません。ここでの推奨事項は、開始点として解釈する必要があります。
An implementation SHOULD:
実装は：
o Ensure any fields prior to TLV Length are consistent with RFC 6378, particularly Section 4.2 of that document.
o TLV長より前のフィールドがRFC 6378、特にそのドキュメントのセクション4.2と一致していることを確認してください。
o Ensure the overall length of the message matches the value in the TLV Length + 12.
o メッセージの全長がTLV長+ 12の値と一致することを確認してください。
o Check that the sum of the lengths of all TLVs matches the value in the TLV Length.
o すべてのTLVの長さの合計がTLV長の値と一致することを確認します。
If an implementation receives a message that fails any malformed message checks, it MUST drop the message and SHOULD alert the operator to the malformed message. The method(s) used to alert the operator are outside the scope of this document but may include things like syslog or console messages.
実装が不正なメッセージチェックに失敗したメッセージを受信した場合、そのメッセージをドロップし、不正なメッセージについてオペレーターに警告する必要があります（SHOULD）。オペレーターへの警告に使用される方法は、このドキュメントの範囲外ですが、syslogやコンソールメッセージなどが含まれる場合があります。
If a message is deemed to be properly formed, an implementation SHOULD check all TLVs to ensure that it knows what to do with them. A well-formed but unknown or unexpected TLV value MUST be ignored, and the rest of the message processed as if the ignored TLV did not exist. An implementation detecting a malformed TLV SHOULD alert the operator as described in Section 2.2.1.
メッセージが適切に形成されていると見なされる場合、実装はすべてのTLVをチェックして、それらが何をすべきかを認識していることを確認する必要があります。整形式だが不明または予期しないTLV値は無視する必要があり、残りのメッセージは、無視されたTLVが存在しないかのように処理されます。不正なTLVを検出する実装は、セクション2.2.1で説明されているようにオペレーターに警告する必要があります。
Issue #2 in the liaison statement identifies a case where a strict reading of RFC 6378 leaves a node reporting an inaccurate status:
リエゾンステートメントの問題＃2は、RFC 6378を厳密に読み取ると、ノードが不正確なステータスを報告したままになる場合を示しています。
A node can end up sending incorrect status -- NR(0,1) -- despite the failure of the protection LSP (P-LSP). This is clearly not correct, as a node should not be sending NR if it has a local failure. To address this issue, the fourth bullet in Section 4.3.3.3 of RFC 6378 is replaced with the following three bullets:
保護LSP（P-LSP）の障害にもかかわらず、ノードが誤ったステータス（NR（0,1））を送信する可能性があります。ノードにローカル障害がある場合、ノードはNRを送信してはならないため、これは明らかに正しくありません。この問題に対処するため、RFC 6378のセクション4.3.3.3の4番目の箇条書きは、次の3つの箇条書きに置き換えられます。
o If the current state is due to a local or remote Manual Switch, a local Signal Fail indication on the protection path SHALL cause the LER to enter local Unavailable state and begin transmission of an SF(0,0) message.
o 現在の状態がローカルまたはリモートの手動切り替えによるものである場合、保護パス上のローカルの信号障害表示により、LERはローカルの使用不可状態に入り、SF（0,0）メッセージの送信を開始する必要があります。
o If the LER is in local Protecting Administrative state due to a local Forced Switch, a local Signal Fail indication on the protection path SHALL be ignored.
o ローカルの強制切り替えのためにLERがローカルの保護管理状態にある場合、保護パス上のローカルの信号障害の表示は無視する必要があります。
o If the LER is in remote Protecting Administrative state due to a remote Forced Switch, a local Signal Fail indication on the protection path SHALL cause the LER to remain in remote Protecting administrative state and transmit an SF(0,1) message.
o リモートの強制切り替えのためにLERがリモートの保護管理状態にある場合、保護パス上のローカルの信号障害の表示により、LERはリモートの保護管理状態のままになり、SF（0,1）メッセージを送信します。
PSC has no explicit facility to negotiate any properties of the protection domain. It does, however, have the ability to signal two properties of that domain, via the Protection Type (PT) and Revertive (R) bits. RFC 6378 specifies that if these bits do not match an operator "SHALL [be notified]" (PT, Section 4.2.3) or "SHOULD be notified" (R, Section 4.2.4). However, there is no text that specifies the behavior of the end nodes of a protection domain in case of a mismatch. This section provides that text, as requested by issue #7 in the liaison statement.
PSCには、保護ドメインのプロパティをネゴシエートする明示的な機能はありません。ただし、保護ドメイン（PT）およびリバーティブ（R）ビットを介して、そのドメインの2つのプロパティを通知する機能があります。 RFC 6378は、これらのビットが演算子に一致しない場合、「SHALL [通知される]」（PT、セクション4.2.3）または「SHOULD通知される」（R、セクション4.2.4）と規定しています。ただし、不一致の場合の保護ドメインのエンドノードの動作を指定するテキストはありません。このセクションでは、連絡文の第7号で要求されているテキストを提供します。
The behavior of the protection domain depends on the exact Protection Type (PT) mismatch. Section 4.2.3 of RFC 6378 specifies three protection types -- bidirectional switching using a permanent bridge, bidirectional switching using a selector bridge, and unidirectional switching using a permanent bridge. They are abbreviated here as BP, BS, and UP.
保護ドメインの動作は、正確な保護タイプ（PT）の不一致によって異なります。 RFC 6378のセクション4.2.3では、3つの保護タイプが指定されています。永続的なブリッジを使用する双方向スイッチング、セレクターブリッジを使用する双方向スイッチング、永続的なブリッジを使用する単方向スイッチングです。ここでは、BP、BS、およびUPと省略されます。
There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP, BS}. The priority is:
3つの不一致の可能性があります：{BP、UP}、{BP、BS}、および{UP、BS}。優先順位は次のとおりです。
UP > BS > BP
UP> BS> BP
In other words:
言い換えると：
o If the PT mismatch is {BP, UP}, the node transmitting BP MUST switch to UP mode if it is supported.
o PTの不一致が{BP、UP}の場合、サポートされている場合、BPを送信するノードはUPモードに切り替える必要があります。
o If the PT mismatch is {BP, BS}, the node transmitting BP MUST switch to BS mode if it is supported.
o PTの不一致が{BP、BS}の場合、サポートされている場合、BPを送信するノードはBSモードに切り替える必要があります。
o If the PT mismatch is {UP, BS}, the node transmitting BS MUST switch to UP mode if it is supported.
o PTの不一致が{UP、BS}の場合、サポートされている場合、BSを送信するノードはUPモードに切り替える必要があります。
If a node does not support a mode to which it is required to switch, then that node MUST behave as in Section 4.3.
ノードが切り替える必要があるモードをサポートしていない場合、そのノードはセクション4.3のように動作する必要があります。
The R bit indicates whether the protection domain is in revertive or non-revertive behavior. If the R bits do not match, the node indicating non-revertive MUST switch to Revertive if it is supported. If it is not supported, a node must behave as in Section 4.3.
Rビットは、保護ドメインがリバーティブ動作か非リバーティブ動作かを示します。 Rビットが一致しない場合、非リバーティブを示すノードは、サポートされている場合はリバーティブに切り替える必要があります。サポートされていない場合、ノードはセクション4.3のように動作する必要があります。
An implementation may not support all three PT modes and/or both R modes, and thus a pair of nodes may be unable to converge on a common mode. This creates a permanent mismatch, resolvable only by operator intervention. An implementation SHOULD alert the operator to an irreconcilable mismatch.
実装は3つすべてのPTモードまたは両方のRモード、あるいはその両方をサポートしない場合があるため、ノードのペアは共通モードに収束できない場合があります。これは永久的なミスマッチを引き起こし、オペレーターの介入によってのみ解決できます。実装は、調整不可能な不一致をオペレーターに警告する必要があります（SHOULD）。
It is desirable to allow the protection domain to function in a non-failure mode even if there is a mismatch, as the mismatches of PT or R have to do with how nodes recover from a failure. An implementation SHOULD allow traffic to be sent on the Working LSP as long as there is no failure (e.g., NR state) regardless of any PT or R mismatch.
PTまたはRの不一致はノードの障害からの回復方法と関係があるため、不一致があっても保護ドメインが非障害モードで機能できるようにすることが望ましいです。実装では、PTまたはRの不一致に関係なく、障害（NR状態など）がない限り、トラフィックを現用LSPで送信できるようにする必要があります（SHOULD）。
If there is a trigger that would cause the protection LSP to be used, such as SF or MS, a node MUST NOT use the protection LSP to carry traffic.
SFやMSなどの保護LSPが使用される原因となるトリガーがある場合、ノードはトラフィックを運ぶために保護LSPを使用してはなりません（MUST NOT）。
Issue #8 in the liaison statement identifies a deadlock case where each node can end up sending NR(0,1) when it should instead be in the process of recovering from the failure (i.e., entering into WTR or DNR, as appropriate for the protection domain). The root of the issue is that a pair of nodes can simultaneously enter WTR state, receive an out-of-date SF-W indication, transition into a remotely triggered WTR, and remain in remotely triggered WTR waiting for the other end to trigger a change in status.
リエゾンステートメントの問題＃8は、デッドロックのケースを示しています。各ノードは、障害からの回復（つまり、WTRまたはDNRに入る必要がある場合）の代わりに、NR（0,1）を送信することになります保護ドメイン）。問題の根本は、ノードのペアが同時にWTR状態に入り、古いSF-W指示を受信し、リモートでトリガーされたWTRに移行し、もう一方の端がステータスの変化。
In the case identified in issue #8, each node can end up sending NR(0,1), which is an indication that the transmitting node has no local failure, but is instead reacting to the remote SF-W. If a node that receives NR(0,1) is in fact not indicating a local error, the correct behavior for the receiving node is to take the received NR(0,1) as an indication that there is no error in the protection domain, and recovery procedures (WTR or DNR) should begin.
問題＃8で識別されたケースでは、各ノードがNR（0,1）を送信する可能性があり、これは送信ノードにローカル障害がないことを示していますが、代わりにリモートSF-Wに反応しています。 NR（0,1）を受信するノードが実際にローカルエラーを示していない場合、受信ノードの正しい動作は、受信したNR（0,1）を保護ドメインにエラーがないことを示すものと見なすことです。 、回復手順（WTRまたはDNR）が開始されます。
This is addressed by adding the following text as the penultimate bullet in Section 4.3.3.4 of RFC 6378:
この問題は、RFC 6378のセクション4.3.3.4の最後から2番目の箇条書きとして次のテキストを追加することで解決されています。
o If a node is in Protecting Failure state due to a remote SF-W and receives NR(0,1), this SHALL cause the node to begin recovery procedures. If the LER is configured for revertive behavior, it enters into Wait-to-Restore state, starts the WTR timer, and begins transmitting WTR(0,1). If the LER is configured for non-revertive behavior, it enters into Do-Not-Revert state and begins transmitting a DNR(0,1) message.
o リモートSF-Wが原因でノードがProtecting Failure状態にあり、NR（0,1）を受信した場合、これによりノードは回復手順を開始する必要があります（SHALL）。 LERがリバーティブ動作用に構成されている場合、LERは待機から復元状態に入り、WTRタイマーを開始し、WTR（0,1）の送信を開始します。 LERが非リバーティブ動作用に構成されている場合、それはDo-Not-Revert状態に入り、DNR（0,1）メッセージの送信を開始します。
Additionally, the penultimate bullet in Section 4.3.3.3 is changed from
さらに、セクション4.3.3.3の最後から2番目の箇条書きは、
o A remote NR(0,0) message SHALL be ignored if in local Protecting administrative state.
o ローカルの保護管理状態の場合、リモートNR（0,0）メッセージは無視する必要があります。
to
と
o A remote No Request message SHALL be ignored if in local Protecting administrative state.
o ローカルの保護管理状態の場合、リモートの要求なしメッセージは無視する必要があります。
This indicates that a remote NR triggers the same behavior regardless of the value of FPath and Path. This change does not directly address issue #8, but it fixes a similar issue -- if a node receives NR while in Remote administrative state, the value of FPath and Path have no bearing on the node's reaction to this NR.
これは、FPathとPathの値に関係なく、リモートNRが同じ動作をトリガーすることを示しています。この変更は問題＃8に直接対処していませんが、同様の問題を修正しています。ノードがリモート管理状態のときにNRを受信した場合、FPathとPathの値は、このNRに対するノードの反応に影響しません。
RFC 6378 describes the PSC state machine. Figure 1 in Section 3 of RFC 6378 shows two inputs into the PSC Control logic -- Local Request logic and Remote PSC Request. When there is only one input into the PSC Control logic -- a local request or a remote request but not both -- the PSC Control logic decides what that input signifies and then takes one or more actions, as necessary. This is what the PSC State Machine in Section 4.3 of RFC 6378 describes.
RFC 6378は、PSCステートマシンについて説明しています。 RFC 6378のセクション3の図1は、PSC制御ロジックへの2つの入力（ローカル要求ロジックとリモートPSC要求）を示しています。 PSC制御ロジックへの入力が1つだけある場合（ローカル要求またはリモート要求で両方ではない）、PSC制御ロジックはその入力が何を意味するかを決定し、必要に応じて1つ以上のアクションを実行します。これは、RFC 6378のセクション4.3のPSCステートマシンで説明されています。
RFC 6378 does not sufficiently describe the behavior in the face of multiple inputs into the PSC Control Logic (one Local Request and one Remote Request). This section clarifies the expected behavior.
RFC 6378は、PSC制御ロジックへの複数の入力（1つのローカル要求と1つのリモート要求）に直面した場合の動作を十分に説明していません。このセクションでは、予想される動作を明らかにします。
There are two cases to think about when considering dual inputs into the PSC Control logic. The first is when the same request is presented from both local and remote sources. One example of this case is a Forced Switch (FS) configured on both ends of an LSP. This will result in the PSC Control logic receiving both a local FS and remove FS. For convenience, this scenario is written as [L(FS), R(FS)] -- that is, Local(Forced Switch) and Remote(Forced Switch).
PSC制御ロジックへのデュアル入力を検討する際に考慮すべき2つのケースがあります。 1つ目は、ローカルソースとリモートソースの両方から同じリクエストが送信される場合です。このケースの1つの例は、LSPの両端で構成された強制スイッチ（FS）です。これにより、PSC制御ロジックがローカルFSと削除FSの両方を受信します。便宜上、このシナリオは[L（FS）、R（FS）]として記述されています。つまり、ローカル（強制切り替え）とリモート（強制切り替え）です。
The second case, which is handled in exactly the same way as the first, is when the two inputs into the PSC Control logic describe different events. There are a number of variations on this case. One example is when there is a Lockout of Protection from the Local request logic and a Signal Fail on the Working path from the Remote PSC Request. This is shortened to [L(LO), R(SF-W)].
最初のケースとまったく同じ方法で処理される2番目のケースは、PSC制御ロジックへの2つの入力が異なるイベントを記述する場合です。このケースにはいくつかのバリエーションがあります。 1つの例は、ローカル要求ロジックからの保護のロックアウトがあり、リモートPSC要求からの現用パスに信号障害がある場合です。これは[L（LO）、R（SF-W）]に短縮されます。
In both cases, the question is not how the PSC Control logic decides which of these is the one it acts upon. Section 4.3.2 of RFC 6378 lists the priority order and prioritizes the local input over the remote input in case both inputs are of the same priority. So, in the first example it is the local SF that drives the PSC Control logic, and in the second example it is the local Lockout that drives the PSC Control logic.
どちらの場合も、問題は、PSC制御ロジックがこれらのどちらに作用するかをどのように決定するかではありません。 RFC 6378のセクション4.3.2は、優先順位をリストし、両方の入力が同じ優先順位である場合にリモート入力よりもローカル入力を優先します。したがって、最初の例では、PSC制御ロジックを駆動するのはローカルSFであり、2番目の例では、PSC制御ロジックを駆動するのはローカルロックアウトです。
The point that this section clears up is around what happens when the highest-priority input goes away. Consider the first case. Initially, the PSC Control logic has [L(FS), R(FS)], and L(FS) is driving PSC's behavior. When L(FS) is removed, but R(FS) remains, what does PSC do? A strict reading of the Finite State Machine (FSM) would suggest that PSC transition from PA:F:L into N, and at some future time (perhaps after the remote request refreshes), PSC would transition from N to PA:F:R. This is an unreasonable behavior, as there is no sensible justification for a node behaving as if things were normal (i.e., N state) when it is clear that they are not.
このセクションがクリアするポイントは、最も優先度の高い入力がなくなったときに何が起こるかについてです。最初のケースを考えてみましょう。最初、PSC制御ロジックには[L（FS）、R（FS）]があり、L（FS）がPSCの動作を駆動しています。 L（FS）が削除され、R（FS）が残っている場合、PSCは何をしますか？有限状態機械（FSM）を厳密に読むと、PSCがPA：F：LからNに移行し、将来（おそらくリモート要求が更新された後）に、PSCがNからPA：F：Rに移行することが示唆されます。 。ノードが正常でない（つまり、N状態）かのように振る舞うノードには、それらが正常でないことが明らかな場合に合理的な正当化がないため、これは不合理な動作です。
The second case is similar. If a node starts with [L(LO), R(SF-W)] and the local lockout is removed, a strict reading of the state machine would suggest that the node transition from UA:LO:L to N, and then at some future time presumably notice the R(SF-W) and transition from N to PF:W:R. As with the first case, this is clearly not a useful behavior.
2番目のケースも同様です。ノードが[L（LO）、R（SF-W）]で始まり、ローカルロックアウトが削除された場合、ステートマシンを厳密に読み取ると、ノードがUA：LO：LからNに移行し、次に将来的には、R（SF-W）とNからPF：W：Rへの移行に気付くでしょう。最初のケースと同様に、これは明らかに有用な動作ではありません。
In both cases, the request that was driving PSC's behavior was removed. What should happen is that the PSC Control logic should, upon removal of an input, immediately reevaluate all other inputs to decide on the next course of action. This requires an implementation to store the most recent local and remote inputs regardless of their eventual use as triggers for the PSC Control Logic.
どちらの場合も、PSCの動作を促進していた要求は削除されました。 PSC制御ロジックは、入力が削除されるとすぐに他のすべての入力を再評価して、次のアクションコースを決定する必要があります。これには、PSC制御ロジックのトリガーとしての最終的な使用に関係なく、最新のローカルおよびリモート入力を格納する実装が必要です。
There is also a third case. Consider a node with [L(FS), R(LO)]. At some point in time, the remote node replaces its Lockout request with a Signal Fail on Working, so that the inputs into the PSC Control logic on the receiving node go to [L(FS), R(SF-W)]. Similar to the first two cases, the node should immediately reevaluate both its local and remote inputs to determine the highest priority among them and act on that input accordingly. That is in fact what happens, as defined in Section 4.3.3 of RFC 6378:
3番目のケースもあります。 [L（FS）、R（LO）]のノードを考えます。ある時点で、リモートノードはそのロックアウト要求を動作時の信号障害に置き換え、受信ノードのPSC制御ロジックへの入力が[L（FS）、R（SF-W）]に送られるようにします。最初の2つのケースと同様に、ノードはローカル入力とリモート入力の両方をすぐに再評価して、それらの間で最高の優先順位を決定し、それに応じてその入力に基づいて行動する必要があります。 RFC 6378のセクション4.3.3で定義されているように、実際にそれが起こります。
When a LER is in a remote state, i.e., state transition in reaction to a PSC message received from the far-end LER, and receives a new PSC message from the far-end LER that indicates a contradictory state, e.g., in remote Unavailable state receiving a remote FS(1,1) message, then the PSC Control logic SHALL reevaluate all inputs (both the local input and the remote message) as if the LER is in the Normal state.
LERがリモート状態にあるとき、つまり、遠端LERから受信したPSCメッセージに反応して状態が遷移し、遠隔状態のLERから新しいPSCメッセージを受信したとき。状態がリモートFS（1,1）メッセージを受信している場合、PSC制御ロジックは、LERが通常状態であるかのように、すべての入力（ローカル入力とリモートメッセージの両方）を再評価する必要があります（SHALL）。
This section extends that paragraph to handle the first two cases. The essence of the quoted paragraph is that when faced with multiple inputs, PSC must reevaluate any changes as if it were in Normal state. So, the quoted paragraph is replaced with the following text:
このセクションでは、最初の2つのケースを処理するようにその段落を拡張します。引用されたパラグラフの本質は、複数の入力に直面した場合、PSCはすべての変更を通常の状態であるかのように再評価する必要があることです。したがって、引用された段落は次のテキストに置き換えられます。
The PSC Control logic may simultaneously have Local and Remote requests, and the highest priority of these requests ultimately drives the behavior of the PSC Control logic. When this highest-priority request is removed or is replaced with another input, then the PSC Control logic SHALL immediately reevaluate all inputs (both the local input and the remote message), transitioning into a new state only upon reevaluation of all inputs.
PSC制御ロジックは、ローカル要求とリモート要求を同時に持つ可能性があり、これらの要求の最高の優先順位が最終的にPSC制御ロジックの動作を駆動します。この最高優先度の要求が削除されるか、別の入力に置き換えられると、PSC制御ロジックはすべての入力（ローカル入力とリモートメッセージの両方）をすぐに再評価し、すべての入力の再評価時にのみ新しい状態に移行する必要があります。
These changes and clarifications raise no new security concerns. RFC 6941 [RFC6941] provides the baseline security discussion for MPLS-TP, and PSC (as described in both RFC 6378 and this document) falls under that umbrella. Additionally, Section 2.2 clarifies how to react to malformed or unexpected messages.
これらの変更と明確化によって、新しいセキュリティ上の懸念は生じません。 RFC 6941 [RFC6941]はMPLS-TPのベースラインセキュリティの議論を提供し、PSC（RFC 6378とこのドキュメントの両方で説明されている）はその傘下に入ります。さらに、セクション2.2では、不正なメッセージや予期しないメッセージへの対応方法を明確にしています。
IANA has marked the value 0 in the "MPLS PSC TLV Registry" as "Reserved, not to be allocated" and updated the references to show [RFC6378] and this document (RFC 7324). Note that this document provides documentation of an action already taken by IANA but not recorded in RFC 6378.
IANAは、「MPLS PSC TLVレジストリ」の値0を「予約済み、割り当てなし」としてマークし、[RFC6378]とこのドキュメント（RFC 7324）を示すように参照を更新しました。このドキュメントは、IANAによってすでに実行されているがRFC 6378には記録されていないアクションのドキュメントを提供することに注意してください。
The author of this document thanks Taesik Cheung, Alessandro D'Alessandro, Annamaria Fulignoli, Sagar Soni, George Swallow, and Yaacov Weingarten for their contributions and review, and Adrian Farrel for the text of Section 2.
このドキュメントの執筆者は、Taesik Cheung、Alessandro D'Alessandro、Annamaria Fulignoli、Sagar Soni、George Swallow、Yaacov Weingartenの各氏の貢献とレビュー、およびセクション2のテキストを提供してくれたAdrian Farrelに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC6378] Weingarten、Y.、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、2011年10月。
[LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks", <https://datatracker.ietf.org/ liaison/1205/>.
[LIAISON] ITU-T SG15、「連絡声明：勧告ITU-T G.8131 / Y.1382改訂-MPLS-TPネットワークの線形保護スイッチング」、<https://datatracker.ietf.org/ liaison / 1205 / >。
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941] Fang、L.、Niven-Jenkins、B.、Mansfield、S。、およびR. Graveman、「MPLS Transport Profile（MPLS-TP）Security Framework」、RFC 6941、2013年4月。
[RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, June 2014.
[RFC7271] Ryoo、J.、Gray、E.、van Helvoort、H.、D'Alessandro、A.、Cheung、T。、およびE. Osborne、「MPLS Transport Profile（MPLS-TP）Linear Protection to Match the同期デジタル階層、光トランスポートネットワーク、およびイーサネットトランスポートネットワークオペレーターの運用上の期待」、RFC 7271、2014年6月。
Author's Address
著者のアドレス
Eric Osborne
エリック・オズボーン
EMail: eric.osborne@notcom.com