Internet Engineering Task Force (IETF) E. Osborne
Request for Comments: 7324 July 2014
Updates: 6378
Category: Standards Track
ISSN: 2070-1721
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.
这是一份互联网标准跟踪文件。
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/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.
版权所有（c）2014 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]的一些更新。其中一个提供了一些关于在PSC中使用TLV的规则和建议。其中三个更新解决了ITU联络声明“建议ITU-T G.8131/Y.1382修订版-MPLS-TP网络线性保护交换”[联络]中确定的问题2、#7和#8。另一种方法清除了RFC6378中没有很好解释的行为。这些更新不是对协议包格式或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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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包含三个字段，如下所示：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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".
对类型值进行编码的两个八位组字段。类型值记录在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.
两个八位字节的字段，对值字段的长度进行八位字节编码。此字段的值必须是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的有效载荷。此字段的长度（即长度字段的值）必须是4个八位字节的倍数，因此此字段可能包含显式填充。每个TLV的长度是其三个字段的长度之和：值字段的长度+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.
建议实施错误和边界检查，以确保接收到的消息（如果格式不正确）得到处理，从而将此格式对网络及其设备行为的影响降至最低。本节介绍了两个方面——格式错误的消息和格式良好但意外的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.
如果实现收到的消息未通过任何格式错误的消息检查，则必须删除该消息，并应向操作员发出格式错误消息的警报。用于提醒操作员的方法不在本文档的范围内，但可能包括系统日志或控制台消息等内容。
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不存在。如第2.2.1节所述，检测到错误TLV的实施应提醒操作员。
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节中的第四个项目符号替换为以下三个项目符号：
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）位向该域的两个属性发送信号。RFC 6378规定，如果这些位不匹配，操作员“应[通知]”（PT，第4.2.3节）或“应通知”（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节规定了三种保护类型——使用永久电桥的双向切换、使用选择器电桥的双向切换和使用永久电桥的单向切换。它们在这里缩写为BP、BS和UP。
There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP, BS}. The priority is:
有三种可能的不匹配：{BP，UP}，{BP，BS}，和{UP，BS}。优先事项是：
UP > BS > BP
向上>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.
一个实现可能不支持所有三个PT模式和/或两个R模式，因此一对节点可能无法收敛于公共模式。这会造成永久性不匹配，只能通过操作员干预解决。实施应提醒操作员注意不可调和的不匹配。
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的失配与节点如何从故障中恢复有关。实现应允许在工作LSP上发送通信量，只要没有故障（例如，NR状态），无论PT或R是否不匹配。
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.
如果存在会导致使用保护LSP的触发器，例如SF或MS，则节点不得使用保护LSP承载流量。
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确定了一种死锁情况，在这种情况下，每个节点都可以发送NR（0,1），而此时它应该处于从故障中恢复的过程中（即进入WTR或DNR，视保护域而定）。问题的根源在于，一对节点可以同时进入WTR状态，接收过期的SF-W指示，转换为远程触发的WTR，并保持在远程触发的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节中添加以下文字作为倒数第二个项目符号来解决此问题：
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而处于保护故障状态，并收到NR（0,1），这将导致节点开始恢复程序。如果LER配置为还原行为，它将进入等待还原状态，启动WTR计时器，并开始传输WTR（0,1）。如果LER配置为非还原行为，则它将进入不还原状态，并开始传输DNR（0,1）消息。
Additionally, the penultimate bullet in Section 4.3.3.3 is changed from
此外，第4.3.3.3节中倒数第二个项目符号从
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.
RFC6378描述了PSC状态机。RFC 6378第3节中的图1显示了PSC控制逻辑的两个输入——本地请求逻辑和远程PSC请求。当PSC控制逻辑只有一个输入时——本地请求或远程请求，但不是两者都有——PSC控制逻辑决定该输入的含义，然后根据需要采取一个或多个操作。这是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控制逻辑中的多个输入（一个本地请求和一个远程请求）时的行为。本节阐明了预期的行为。
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控制逻辑的双输入时，需要考虑两种情况。第一种情况是，来自本地和远程源的请求都相同。这种情况的一个示例是配置在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)].
第二种情况的处理方式与第一种情况完全相同，即PSC控制逻辑的两个输入描述不同的事件。这个案子有很多不同的说法。一个例子是，本地请求逻辑的保护锁定，远程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节列出了优先级顺序，并在两个输入具有相同优先级的情况下，将本地输入优先于远程输入。因此，在第一个示例中，本地SF驱动PSC控制逻辑，在第二个示例中，本地锁定驱动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.
第二种情况类似。如果一个节点以[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:
还有第三种情况。考虑具有[L（fs），r（LO）]的节点。在某个时间点，远程节点将其锁定请求替换为工作失败信号，以便接收节点上PSC控制逻辑的输入转到[L（FS），R（SF-W）]。与前两种情况类似，节点应立即重新评估其本地和远程输入，以确定其中的最高优先级，并相应地对该输入采取行动。事实上，正如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处于正常状态。
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:
本节扩展了该段，以处理前两种情况。引用段落的实质是，当面对多个输入时，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.
本文件的作者感谢张泰植、亚历山德罗·德亚历山德罗、安娜玛丽亚·富利格诺利、萨加尔·索尼、乔治·斯沃恩和雅科夫·温加滕的贡献和评论，并感谢阿德里安·法雷尔提供第2节的文本。
[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]Y.Weingarten、S.Bryant、E.Osborne、N.Sprecher和A.Fulignoli，“MPLS传输模式（MPLS-TP）线性保护”，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/>.
[联络]ITU-T SG15，“联络声明：建议ITU-T G.8131/Y.1382修订版-MPLS-TP网络的线性保护交换”<https://datatracker.ietf.org/ 联络/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传输配置文件（MPLS-TP）安全框架”，RFC 69412013年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传输模式（MPLS-TP）线性保护，以满足同步数字体系、光传输网络和以太网传输网络运营商的运营期望”，RFC 7271，2014年6月。
Author's Address
作者地址
Eric Osborne
埃里克·奥斯本
EMail: eric.osborne@notcom.com
EMail: eric.osborne@notcom.com