Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 8237 Monoski LLC
Category: Standards Track G. Swallow
ISSN: 2070-1721 SETC
E. Bellagamba
Ericsson
October 2017
Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 8237 Monoski LLC
Category: Standards Track G. Swallow
ISSN: 2070-1721 SETC
E. Bellagamba
Ericsson
October 2017
MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs
静态PWs的MPLS标签交换路径（LSP）伪线（PW）状态刷新减少
Abstract
摘要
This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP.
本文档描述了一种方法，用于生成为多协议标签交换（MPLS）标签交换路径（LSP）上的静态配置PW发送的聚合伪线（PW）状态消息，以指示LSP上承载的一个或多个PW的状态。
The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.
发送PW状态信息的方法不是新的；但是，此协议扩展允许服务提供商（SP）可靠地监视单个PW状态，同时不会用多个定期状态消息淹没网络。这是通过为同一LSP中分组的所有PW发送单个累积摘要状态验证消息来实现的。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8237.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8237.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Terminology ................................................4
1.3. Notational Conventions .....................................5
2. PW Status Refresh Reduction Protocol ............................5
2.1. Protocol States ............................................5
2.1.1. INACTIVE ............................................5
2.1.2. STARTUP .............................................6
2.1.3. ACTIVE ..............................................6
2.2. Timer Value Change Transition Procedure ....................6
3. PW Status Refresh Reduction Procedure ...........................7
4. PW Status Refresh Reduction Message Encoding ....................8
5. PW Status Refresh Reduction Control Messages ...................11
5.1. Notification Message ......................................12
5.2. PW Configuration Message ..................................12
5.2.1. MPLS-TP Tunnel ID ..................................13
5.2.2. PW ID Configured List ..............................14
5.2.3. PW ID Unconfigured List ............................15
6. PW Provisioning Verification Procedure .........................15
6.1. PW ID List Advertising and Processing .....................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................17
8.1. PW Status Refresh Reduction Message Types .................17
8.2. PW Configuration Message Sub-TLVs .........................17
8.3. PW Status Refresh Reduction Notification Codes ............18
8.4. PW Status Refresh Reduction Message Flags .................18
8.5. G-ACh Registry Allocation .................................19
8.6. Guidance for Designated Experts ...........................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Authors' Addresses ................................................20
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Terminology ................................................4
1.3. Notational Conventions .....................................5
2. PW Status Refresh Reduction Protocol ............................5
2.1. Protocol States ............................................5
2.1.1. INACTIVE ............................................5
2.1.2. STARTUP .............................................6
2.1.3. ACTIVE ..............................................6
2.2. Timer Value Change Transition Procedure ....................6
3. PW Status Refresh Reduction Procedure ...........................7
4. PW Status Refresh Reduction Message Encoding ....................8
5. PW Status Refresh Reduction Control Messages ...................11
5.1. Notification Message ......................................12
5.2. PW Configuration Message ..................................12
5.2.1. MPLS-TP Tunnel ID ..................................13
5.2.2. PW ID Configured List ..............................14
5.2.3. PW ID Unconfigured List ............................15
6. PW Provisioning Verification Procedure .........................15
6.1. PW ID List Advertising and Processing .....................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................17
8.1. PW Status Refresh Reduction Message Types .................17
8.2. PW Configuration Message Sub-TLVs .........................17
8.3. PW Status Refresh Reduction Notification Codes ............18
8.4. PW Status Refresh Reduction Message Flags .................18
8.5. G-ACh Registry Allocation .................................19
8.6. Guidance for Designated Experts ...........................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Authors' Addresses ................................................20
When PWs use a Multiprotocol Label Switching (MPLS) network as the Packet Switched Network (PSN), they are set up using static label assignment per Section 4 of [RFC8077], and the PW status information is propagated using the method described in [RFC6478]. There are two basic modes of operation described in [RFC6478], Section 5.3: (1) periodic retransmission of non-zero status messages and (2) a simple acknowledgment of PW status (Section 5.3.1 of [RFC6478]). The LSP-level protocol described below applies to the case when
当PWs使用多协议标签交换（MPLS）网络作为分组交换网络（PSN）时，根据[RFC8077]第4节使用静态标签分配进行设置，并使用[RFC6478]中描述的方法传播PW状态信息。[RFC6478]第5.3节中描述了两种基本的操作模式：（1）非零状态消息的定期重新传输和（2）PW状态的简单确认（RFC6478第5.3.1节）。下面描述的LSP级协议适用于以下情况：
PW status is acknowledged immediately with a requested refresh value of zero (no refresh). In this case, the PW status refresh reduction protocol is necessary for several reasons, such as the following:
PW状态立即得到确认，请求的刷新值为零（无刷新）。在这种情况下，出于以下几个原因，PW状态刷新减少协议是必要的：
i. The PW status refresh reduction protocol greatly increases the scalability of the PW status protocol by reducing the amount of messages that a Provider Edge (PE) needs to periodically send to its neighbors.
i. PW状态刷新减少协议通过减少提供者边缘（PE）需要定期发送给其邻居的消息量，极大地提高了PW状态协议的可伸缩性。
ii. The PW status refresh reduction protocol will detect a remote PE restart.
二,。PW状态刷新减少协议将检测远程PE重启。
iii. If the local state is lost for some reason, the PE needs to be able to request a status refresh reduction from the remote PE.
iii.如果本地状态由于某种原因丢失，则PE需要能够从远程PE请求状态刷新减少。
iv. The PW status refresh reduction protocol can optionally detect a remote PE provisioning change.
iv.PW状态刷新减少协议可以选择性地检测远程PE设置更改。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
FEC: Forwarding Equivalence Class
转发等价类
LDP: Label Distribution Protocol
标签分发协议
LSP: Label Switched Path
标签交换路径
MS-PW: Multi-Segment Pseudowire
MS-PW：多段伪导线
PE: Provider Edge
PE：提供程序边缘
PW: Pseudowire
伪线
S-PE: Switching Provider Edge Node of MS-PW
S-PE:MS-PW的交换提供程序边缘节点
SS-PW: Single-Segment Pseudowire
SS-PW：单段伪导线
T-PE: Terminating Provider Edge Node of MS-PW
T-PE：终止MS-PW的提供程序边缘节点
All multiple-word atomic identifiers use underscores ("_") between the words to join the words. Many of the identifiers are composed of a concatenation of other identifiers. These are expressed using double-colon ("::") notation.
所有多个单词原子标识符都在单词之间使用下划线（“\”）来连接单词。许多标识符由其他标识符的串联组成。它们使用双冒号（“：”）表示。
Where the same identifier type is used multiple times in a concatenation, they are qualified by a prefix joined to the identifier by a dash ("-"). For example, Src-Node_ID is the Node_ID of a node referred to as "Src" ("Src" is short for "source").
在串联中多次使用同一标识符类型的情况下，它们由一个前缀限定，该前缀通过破折号（“-”）连接到标识符。例如，Src-Node_ID是被称为“Src”的节点的Node_ID（“Src”是“source”的缩写）。
The notation does not define an implicit ordering of the information elements involved in a concatenated identifier.
该符号不定义串联标识符中涉及的信息元素的隐式顺序。
The PW status refresh reduction protocol consists of a simple message that is sent at the LSP level, using the MPLS Generic Associated Channel (G-ACh) [RFC5586].
PW状态刷新减少协议由使用MPLS通用关联通道（G-ACh）在LSP级别发送的简单消息组成[RFC5586]。
For a particular LSP where the PW status refresh reduction protocol is enabled, a PE using this protocol MUST send the PW status refresh reduction Message as soon as a PW is configured on that LSP. The message is then retransmitted at a locally configured interval indicated in the Refresh Timer field. If no acknowledgment is received, the protocol does not reach the ACTIVE state (Section 2.1.3), and the PE SHOULD NOT send any PW status messages with a Refresh Timer of zero as described in [RFC6478], Section 5.3.1.
对于启用PW状态刷新减少协议的特定LSP，使用此协议的PE必须在该LSP上配置PW后立即发送PW状态刷新减少消息。然后按照刷新计时器字段中指示的本地配置间隔重新传输消息。如果未收到确认，则协议未达到激活状态（第2.1.3节），PE不应发送刷新计时器为零的任何PW状态消息，如[RFC6478]第5.3.1节所述。
It is worth noting that no relationship exists between the locally configured timer for the PW status refresh reduction protocol and the individual PW status Refresh Timers.
值得注意的是，PW状态刷新减少协议的本地配置计时器与单个PW状态刷新计时器之间不存在任何关系。
The protocol can be in three possible states: INACTIVE, STARTUP, and ACTIVE.
协议可以处于三种可能的状态：非活动、启动和活动。
This state is entered when the protocol is turned off. This state is also entered if all PWs on a specific LSP are deprovisioned.
该状态在协议关闭时进入。如果取消提供特定LSP上的所有PW，也会进入此状态。
In this state, the PE transmits periodic PW status refresh reduction Messages with the Ack Session ID (Section 4) set to 0. The PE remains in this state until a PW status refresh message is received with the correct local Session ID in the Ack Session ID field. State can transition from the STARTUP state to the ACTIVE or INACTIVE state.
在此状态下，PE发送Ack会话ID（第4节）设置为0的定期PW状态刷新减少消息。PE保持此状态，直到收到带有Ack会话ID字段中正确的本地会话ID的PW status refresh消息。状态可以从启动状态转换为活动或非活动状态。
This state is entered once the PE receives a PW status refresh reduction Message with the correct local Session ID in the Ack Session ID field within 3.5 times the Refresh Timer field value of the last PW status refresh reduction Message transmitted. This state is immediately exited in the following scenarios:
一旦PE接收到一条PW状态刷新减少消息，且Ack会话ID字段中具有正确的本地会话ID，且在上次发送的PW状态刷新减少消息的刷新计时器字段值的3.5倍之内，则进入该状态。在以下情况下，此状态将立即退出：
i. A valid PW status refresh reduction Message is not received within 3.5 times the current Refresh Timer field value (assuming that a timer transition procedure is not in progress). New state: STARTUP.
i. 在当前刷新计时器字段值的3.5倍内未收到有效的PW状态刷新减少消息（假设计时器转换过程未进行）。新状态：启动。
ii. A PW status refresh reduction Message is received with the wrong Ack Session ID field value or a zero Ack Session ID field value. New state: STARTUP.
二,。收到带有错误Ack会话ID字段值或零Ack会话ID字段值的PW状态刷新减少消息。新状态：启动。
iii. All PWs using the particular LSP are deprovisioned, or the protocol is disabled. New state: INACTIVE.
iii.取消提供使用特定LSP的所有PW，或禁用协议。新状态：不活动。
If a PE needs to change the value of the Refresh Timer field while the PW status refresh reduction protocol is in the ACTIVE state, the following procedure must be followed:
如果在PW状态刷新减少协议处于激活状态时，PE需要更改刷新计时器字段的值，则必须遵循以下步骤：
i. A PW status refresh reduction Message is transmitted with the new timer value.
i. 使用新的定时器值发送PW状态刷新减少消息。
ii. If the new value is greater than the original one, the PE will operate according to the new timer value immediately.
二,。如果新值大于原始值，则PE将立即根据新定时器值运行。
iii. If the new value is smaller than the original one, the PE will operate according to the original timer value for a period 3.5 times the original timer value or until the first valid PW status refresh reduction Message is received.
iii.如果新值小于原始值，则PE将根据原始定时器值运行3.5倍于原始定时器值的时间段，或直到收到第一条有效PW状态刷新减少消息。
A PE receiving a PW status refresh reduction Message with a new timer value will immediately acknowledge the new value via a PW status refresh reduction Message and will start operating according to the new timer value.
收到带有新定时器值的PW状态刷新减少消息的PE将立即通过PW状态刷新减少消息确认新值，并将根据新定时器值开始操作。
When the PW status refresh reduction protocol on a particular LSP is in the ACTIVE state, the PE can send all PW status messages, for PWs on that LSP, with a Refresh Timer value of zero. This greatly decreases the amount of messages that the PE needs to transmit to the remote PE because once the PW status message for a particular PW is acknowledged, further repetitions of that message are no longer necessary.
当特定LSP上的PW状态刷新减少协议处于活动状态时，PE可以发送该LSP上PW的所有PW状态消息，刷新计时器值为零。这大大减少了PE需要传输到远程PE的消息量，因为一旦确认了特定PW的PW状态消息，就不再需要进一步重复该消息。
To further reduce the amount of possible messages when an LSP starts forwarding traffic, care should be taken to permit the PW status refresh reduction protocol to reach the ACTIVE state quickly, and before the first PW status Refresh Timer expires. This can be achieved by using a PW status refresh reduction Message Refresh Timer value that is much smaller than the PW status message Refresh Timer value in use (Section 5.3.1 of [RFC6478]).
为了在LSP开始转发流量时进一步减少可能的消息量，应注意允许PW状态刷新减少协议在第一个PW状态刷新计时器到期之前快速达到活动状态。这可以通过使用比使用中的PW状态消息刷新定时器值小得多的PW状态消息刷新定时器值（RFC6478第5.3.1节）来实现。
If the PW status refresh reduction protocol session is terminated by entering the INACTIVE state or the STARTUP state, the PE MUST immediately resend all the previously sent PW status messages for that particular LSP for which the session was terminated. In this case, the Refresh Timer value MUST NOT be set to 0 and MUST be set according to the local policy of the PE router. Implementations MUST take care to avoid flooding the remote PE with a large number of PW status messages at once. If the PW status refresh reduction protocol session is terminated for administrative reasons and the local PE can still communicate with the remote PE, the local PE SHOULD pace the transmission of PW status messages to the remote PE.
如果PW状态刷新减少协议会话通过进入非活动状态或启动状态而终止，则PE必须立即重新发送会话终止的特定LSP的所有先前发送的PW状态消息。在这种情况下，刷新计时器值不能设置为0，必须根据PE路由器的本地策略进行设置。实现时必须注意避免同时向远程PE发送大量PW状态消息。如果PW status refresh reduction protocol（PW状态刷新减少协议）会话因管理原因而终止，并且本地PE仍然可以与远程PE通信，则本地PE应调整PW状态消息到远程PE的传输速度。
The packet containing the PW status refresh reduction Message is encoded as follows (omitting link-layer information):
包含PW状态刷新减少消息的分组编码如下（省略链路层信息）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS LSP (tunnel) Label Stack Entry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x29 PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Ack Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | Total Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Message Type |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Control Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS LSP (tunnel) Label Stack Entry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x29 PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Ack Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | Total Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Message Type |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Control Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message contains the following fields:
此消息包含以下字段：
* MPLS LSP (tunnel) Label Stack Entry
* MPLS LSP（隧道）标签堆栈条目
The label stack is explained in [RFC3031].
[RFC3031]中对标签堆栈进行了说明。
* GAL
* 女孩
The G-ACh Label (GAL) and the next 4 octets (including the PW OAM Message field as the Channel Type) are explained in Section 2.1 of [RFC5586].
[RFC5586]第2.1节解释了G-ACh标签（GAL）和接下来的4个八位字节（包括作为通道类型的PW OAM消息字段）。
* PW OAM Message
* PW OAM消息
This field indicates the Channel Type in the G-ACh header, as described in Section 2.1 of [RFC5586].
该字段表示G-ACh报头中的信道类型，如[RFC5586]第2.1节所述。
* Session ID
* 会话ID
A non-zero locally selected session number that is not preserved if the local PE restarts.
如果本地PE重新启动，则不会保留的非零本地选定会话号。
In order to get a locally unique Session ID, the recommended choice is to perform a CRC-16 ("CRC" stands for "Cyclic Redundancy Check"), giving as input the following data:
为了获得本地唯一的会话ID，建议选择执行CRC-16（“CRC”代表“循环冗余校验”），输入以下数据：
|YY|MM|DD|HHMMSSLLL|
|年月日|
Where: YY = the last two decimal digits of the current year MM = the two decimal digits of the current month DD = the two decimal digits of the current day HHMMSSLLL = the decimal digits of the current time, expressed in hours (HH), minutes (MM), seconds (SS), and milliseconds (LLL)
式中：YY=当前年份的最后两位小数MM=当前月份的两位小数DD=当前日期的两位小数hhmmsll=当前时间的小数位数，以小时（HH）、分钟（MM）、秒（SS）和毫秒（LLL）表示
If the calculation results in an already-existing Session ID, a unique Session ID can be generated by adding 1 to the result until the Session ID is unique. Any other method to generate a locally unique Session ID is also acceptable.
如果计算结果是一个已经存在的会话ID，则可以通过向结果中添加1生成唯一的会话ID，直到会话ID唯一为止。生成本地唯一会话ID的任何其他方法也是可以接受的。
* Ack Session ID
* 确认会话ID
The Acknowledgment Session ID received from the remote PE.
从远程PE接收的确认会话ID。
* Refresh Timer
* 刷新定时器
A non-zero unsigned 16-bit integer value greater than or equal to 10, expressed in milliseconds, that indicates the desired refresh interval. The default value of 30000 is RECOMMENDED.
大于或等于10的非零无符号16位整数值，以毫秒为单位，表示所需的刷新间隔。建议使用默认值30000。
* Total Message Length
* 总消息长度
Total length in octets of the Checksum, Message Type, Flags, Message Sequence Number, and Control Message Body. A value of zero means that no control message is present and, therefore, that no Checksum or subsequent fields are present either.
校验和、消息类型、标志、消息序列号和控制消息正文的总长度（以八位字节为单位）。值为零表示不存在控制消息，因此也不存在校验和或后续字段。
* Checksum
* 校验和
A 16-bit field containing the one's complement of the one's complement sum of the entire message (including the G-ACh header), with the Checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. Note that when the checksum is not computed, the header of the bundle message will not be covered by any checksum.
一个16位的字段，包含整个报文（包括G-ACh报头）的一个补码和的一个补码，为了计算校验和，校验和字段替换为零。全零值表示未传输校验和。请注意，当未计算校验和时，任何校验和都不会覆盖捆绑消息的头。
* Message Sequence Number
* 消息序列号
An unsigned 16-bit integer that is started from 1 when the protocol enters the ACTIVE state. The sequence number wraps back to 1 when the maximum value is reached. The value 0 is reserved and MUST NOT be used.
协议进入活动状态时从1开始的无符号16位整数。当达到最大值时，序列号回折为1。值0是保留的，不能使用。
* Last Received Message Sequence Number
* 上次收到的消息序列号
The sequence number of the last message received. If no message has yet been received during this session, this field is set to 0.
接收到的最后一条消息的序列号。如果在此会话期间尚未收到任何消息，则此字段设置为0。
* Message Type
* 消息类型
The type of control message that follows. Control message types are allocated in this document and by IANA.
后面的控制消息的类型。控制消息类型在本文档中由IANA分配。
* (U) Unknown flag bit
* （U） 未知标志位
Upon receipt of an unknown message or TLV, if U is clear (0), a notification message with code "Unknown TLV (U-Bit=0)" (code 0x4) MUST be sent to the remote PE, and the keepalive session MUST be terminated by entering the STARTUP state; if U is set (1), the unknown message, or message containing an unknown TLV, MUST be acknowledged and silently ignored, and the following messages, or TLVs, if any, processed as if the unknown message or TLV did not exist. In this case, the PE MAY send back a single notification message per keepalive session with code "Unknown TLV (U-Bit=1)". This last step is OPTIONAL.
在收到未知消息或TLV时，如果U为清除（0），则必须向远程PE发送代码为“未知TLV（U位=0）”（代码0x4）的通知消息，并且必须通过进入启动状态来终止keepalive会话；如果设置了U（1），则必须确认未知消息或包含未知TLV的消息，并以静默方式忽略，并且处理以下消息或TLV（如果有），就像处理未知消息或TLV一样。在这种情况下，PE可能会在每个keepalive会话中返回一条代码为“未知TLV（U位=1）”的通知消息。最后一步是可选的。
* (C) Configuration flag bit
* （C） 配置标志位
The C-Bit is used to signal the end of PW configuration transmission. If it is set, the sending PE has finished sending all of its current configuration information.
C位用于发出PW配置传输结束的信号。如果已设置，则发送PE已完成发送其所有当前配置信息。
* Flags
* 旗帜
The remaining 6 bits of PW status refresh reduction Message Flags to be allocated by IANA. These unallocated bits MUST be set to 0 on transmission and ignored on reception.
IANA分配的剩余6位PW状态刷新减少消息标志。这些未分配的位在传输时必须设置为0，在接收时必须忽略。
* Control Message Body
* 控制消息体
The Control Message Body is defined in Section 5 and is specific to the type of message.
控制消息正文在第5节中定义，并且特定于消息类型。
It should be noted that the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and Control Message Body are OPTIONAL. The Total Message Length field is used to parse how many optional fields are included. Hence, all optional fields that precede a specific field that needs to be included in a specific implementation MUST be included if that optional field is also included.
应注意，校验和、消息序列号、上次接收的消息序列号、消息类型、标志和控制消息正文是可选的。“消息总长度”字段用于分析包含多少可选字段。因此，如果需要包含在特定实现中的特定字段之前的所有可选字段也包括在内，则必须包含该字段之前的所有可选字段。
If any of the above values are outside the specified range, a notification message is returned with code "PW configuration not supported", and the message is ignored.
如果上述任何值超出指定范围，则返回一条通知消息，代码为“PW配置不受支持”，该消息将被忽略。
PW status refresh reduction Control Messages consist of the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and Control Message Body.
PW状态刷新减少控制消息由校验和、消息序列号、上次接收的消息序列号、消息类型、标志和控制消息正文组成。
When a PW status refresh reduction Control Message needs to be sent, the system can attach it to a scheduled PW status refresh reduction Message or send one ahead of time. In any case, PW status refresh reduction Control Messages always piggyback on normal messages.
当需要发送PW状态刷新减少控制消息时，系统可以将其附加到计划PW状态刷新减少消息或提前发送一条。在任何情况下，PW status refresh reduction控制消息总是与正常消息相背载。
A PW status refresh reduction Message is also called a PW status refresh reduction Control Message if it contains a control message construct.
如果PW状态刷新减少消息包含控制消息构造，则该消息也称为PW状态刷新减少控制消息。
There can only be one control message construct per PW status refresh reduction Message. If the U-Bit is set and a PE receiving the PW status refresh reduction Message does not understand the control message, the control message MUST be silently ignored. However, the Message Sequence Number MUST still be acknowledged by sending a Null Notification message back with the appropriate value in the Last Message Received field. If a control message is not acknowledged after 3.5 times the value of the Refresh Timer, a fatal notification -- "Unacknowledged control message" -- MUST be sent, and the PW status refresh reduction session MUST be terminated.
每个PW状态刷新减少消息只能有一个控制消息构造。如果设置了U位，并且接收PW status refresh reduction（PW状态刷新减少）消息的PE不理解控制消息，则必须静默忽略控制消息。但是，仍然必须通过在“最后收到的消息”字段中使用适当的值发送空通知消息来确认消息序列号。如果控制消息在刷新计时器值的3.5倍之后未被确认，则必须发送致命通知——“未确认的控制消息”，并且必须终止PW状态刷新减少会话。
If a PE does not want or need to send a control message, the Checksum and all subsequent fields MUST NOT be sent, and the Total Message Length field is then set to 0.
如果PE不希望或不需要发送控制消息，则不得发送校验和和所有后续字段，然后将消息总长度字段设置为0。
The most common use of the notification message is to acknowledge the reception of a message by indicating the received Message Sequence Number in the Last Received Sequence Number field. The notification message is encoded as follows:
通知消息最常见的用途是通过在最后接收的序列号字段中指示接收的消息序列号来确认消息的接收。通知消息的编码如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Type=0x01 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Type=0x01 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message type is set to 0x01, and the U-Bit is treated as described in Section 4. The Notification Codes are 32-bit quantities assigned by IANA (see the IANA Considerations section). Notification codes are considered either "Error codes" or simple notifications. If the Notification Code is an Error code as indicated in the IANA allocation registry, the keepalive session MUST be terminated by entering the STARTUP state.
消息类型设置为0x01，U位按第4节所述处理。通知代码是IANA分配的32位数量（参见IANA注意事项部分）。通知代码被视为“错误代码”或简单通知。如果通知代码是IANA分配注册表中指示的错误代码，则必须通过进入启动状态来终止keepalive会话。
When there is no notification information to be sent, the notification code is set to 0 to indicate a "Null Notification". The C-Bit MUST always be set to 0 in this type of message. The remaining 6 bits of PW status refresh reduction Message Flags are to be allocated by IANA. These unallocated bits MUST be set to 0 on transmission and ignored on reception.
当没有要发送的通知信息时，通知代码设置为0以表示“空通知”。在这种类型的消息中，C位必须始终设置为0。剩余的6位PW状态刷新减少消息标志将由IANA分配。这些未分配的位在传输时必须设置为0，在接收时必须忽略。
The PW status refresh reduction TLVs are informational TLVs that allow the remote PE to verify certain provisioning information. This message contains a series of sub-TLVs, in no particular order, that contain PW and LSP configuration information. The message has no preset length limit; however, its total length will be limited by the transport network's Maximum Transmission Unit (MTU). PW status refresh reduction Messages MUST NOT be fragmented. If a sender has more configuration information to send than will fit into one PW Configuration Message, it may send additional messages carrying additional TLVs.
PW状态刷新减少TLV是信息性TLV，允许远程PE验证某些设置信息。此消息包含一系列子TLV（无特定顺序），其中包含PW和LSP配置信息。消息没有预设的长度限制；但是，其总长度将受到传输网络最大传输单元（MTU）的限制。PW状态刷新减少消息不得分段。如果发送方要发送的配置信息多于一条PW配置消息中的配置信息，则它可能会发送带有附加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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Type=0x02 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| PW Configuration Message Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Type=0x02 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| PW Configuration Message Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Configuration Message type is set to 0x02. For this message, the U-Bit is set to 1, as processing of these messages is OPTIONAL.
PW配置消息类型设置为0x02。对于此消息，U位设置为1，因为处理这些消息是可选的。
The C-Bit is used to signal the end of PW configuration transmission. If it is set, the sending PE has finished sending all of its current configuration information. The PE transmitting the configuration MUST set the C-Bit on the last PW Configuration Message when all current PW configuration information has been sent.
C位用于发出PW配置传输结束的信号。如果已设置，则发送PE已完成发送其所有当前配置信息。发送所有当前PW配置信息后，发送配置的PE必须在最后一条PW配置消息上设置C位。
PW Configuration Message sub-TLVs have the following generic format:
PW配置消息子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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Value (Continued) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Value (Continued) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the MPLS-TP Tunnel ID ("MPLS-TP" stands for "MPLS Transport Profile"). When the configuration message is used for a particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be sent at least once.
此TLV包含MPLS-TP隧道ID（“MPLS-TP”表示“MPLS传输配置文件”）。当配置消息用于特定的keepalive会话时，必须至少发送一次MPLS-TP隧道ID子TLV。
The MPLS-TP Tunnel ID is encoded as follows:
MPLS-TP隧道ID编码如下：
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=0x01 | Length=20 | MPLS-TP Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| MPLS-TP Tunnel ID (Continued) (20 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x01 | Length=20 | MPLS-TP Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| MPLS-TP Tunnel ID (Continued) (20 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPLS point-to-point tunnel ID is defined in [RFC6370]. The coding used by the node that is the source of a message is:
MPLS点对点隧道ID在[RFC6370]中定义。作为消息源的节点使用的编码为：
Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
Dst-Tunnel_Num
Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
Dst-Tunnel_Num
Note that a single tunnel ID is enough to identify the tunnel and the source end of the message.
请注意，单个隧道ID足以标识隧道和消息的源端。
This OPTIONAL sub-TLV contains a list of the provisioned PWs on the LSP.
此可选子TLV包含LSP上已配置PW的列表。
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=0x02 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW Path ID (Continued) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x02 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW Path ID (Continued) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Path ID is a 32-octet PW path identifier [RFC6370]. The coding used by the node that is the source of a message is:
PW路径ID是一个32个八位组的PW路径标识符[RFC6370]。作为消息源的节点使用的编码为：
AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
Dst-Global_ID::Dst-Node_ID::Dst-AC_ID
AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
Dst-Global_ID::Dst-Node_ID::Dst-AC_ID
The number of PW Path IDs in the TLV will be inferred by the length of the TLV, up to a maximum of 8. The procedure for processing this TLV will be described in Section 6.
TLV中PW路径ID的数量将由TLV的长度推断，最多8个。第6节将描述处理该TLV的程序。
This OPTIONAL sub-TLV contains a list of the PWs that have been deprovisioned on the LSP. Note that sending the same PW address in both the PW ID Configured List sub-TLV and the PW ID Unconfigured List sub-TLV in the same configuration message constitutes a fatal session error. If this error occurs, an error notification message is returned with the Error code "PW Configuration TLV conflict", and the session is terminated by entering the STARTUP state.
此可选子TLV包含LSP上已取消提供的PW列表。请注意，在同一配置消息中，在PW ID配置的列表子TLV和PW ID未配置的列表子TLV中发送相同的PW地址会构成严重的会话错误。如果发生此错误，将返回错误通知消息，错误代码为“PW配置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=0x03 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW Path ID (Continued) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x03 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW Path ID (Continued) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Path ID is a 32-octet PW path identifier as defined in Section 5.2.2.
PW路径ID是第5.2.2节中定义的32个八位组PW路径标识符。
The number of PW Path IDs in the TLV will be inferred by the length of the TLV, up to a maximum of 8.
TLV中PW路径ID的数量将由TLV的长度推断，最多8个。
The advertisement of the PW Configuration Message is OPTIONAL.
PW配置消息的播发是可选的。
A PE that desires to use the PW Configuration Message to verify the configuration of PWs on a particular LSP should advertise its PW configuration to the remote PE on LSPs that have active keepalive sessions. When a PE receives PW configuration information using this protocol and it does not support processing the information or is not willing to process it, it MUST acknowledge all the PW Configuration Messages with the notification code "PW configuration not supported". In this case, the information in the PW Configuration Message is silently ignored. If a PE receives such a notification, it SHOULD stop sending PW Configuration Messages for the duration of the PW status refresh reduction keepalive session.
希望使用PW配置消息验证特定LSP上PW配置的PE应将其PW配置通告给具有活动keepalive会话的LSP上的远程PE。当PE使用此协议接收到PW配置信息，但不支持处理该信息或不愿意处理该信息时，必须确认所有PW配置消息，通知代码为“PW配置不支持”。在这种情况下，PW配置消息中的信息将被静默忽略。如果PE收到这样的通知，它应该在PW状态刷新减少keepalive会话期间停止发送PW配置消息。
If PW configuration information is received, it is used to verify the accuracy of the local configuration information against the remote PE's configuration information. If a configuration mismatch is detected, where a particular PW is configured locally but not on the remote PE, the following actions SHOULD be taken:
如果接收到PW配置信息，它用于对照远程PE的配置信息验证本地配置信息的准确性。如果检测到配置不匹配，在本地配置了特定PW但未在远程PE上配置，则应采取以下措施：
i. The local PW MUST be considered in "Not Forwarding" state (Section 6.3.2 of [RFC8077]).
i. 必须考虑本地PW处于“不转发”状态（RFC8077第6.3.2节）。
ii. The PW Attachment Circuit status is set to reflect the PW fault.
二,。PW附件电路状态设置为反映PW故障。
iii. An alarm SHOULD be raised to a network management system.
iii.应向网络管理系统发出警报。
iv. A notification message with the notification code "PW configuration mismatch" MUST be sent to the remote PE. Only one such message is REQUIRED per configuration message even if the configuration message is split into multiple configuration messages due to individual message-size restrictions on a particular link. Upon receipt of such a message, the receiving PE MAY raise an alarm to a network management system. This alarm MAY be cleared when the configuration is updated.
iv.必须向远程PE发送通知代码为“PW配置不匹配”的通知消息。每个配置消息只需要一条这样的消息，即使由于特定链接上的单个消息大小限制，配置消息被拆分为多条配置消息。在接收到这样的消息时，接收PE可以向网络管理系统发出警报。更新配置时，此警报可能会被清除。
When configuration messages are advertised on a particular LSP, the PE sending the messages needs to checkpoint the configuration information sent by setting the C-Bit when all currently known configuration information has been sent. This process allows the receiving PE to immediately proceed to verify all the currently configured PWs on that LSP, eliminating the need for a long waiting period.
当在特定LSP上播发配置消息时，发送消息的PE需要在发送所有当前已知配置信息时设置C位，以检查发送的配置信息。此过程允许接收PE立即继续验证该LSP上当前配置的所有PW，从而消除了长时间等待的需要。
If a new PW is added to a particular LSP, the PE MUST place the configuration verification of this PW on hold for a period of at least 30 seconds. This is necessary to minimize false-positive events of misconfiguration due to the ends of the PW being slightly out of sync.
如果将新PW添加到特定LSP，PE必须将此PW的配置验证保持至少30秒。这对于最大限度地减少由于PW端部稍微不同步而导致的误报事件是必要的。
The security considerations discussed in [RFC6478] are adequate for the mechanism described in this document, since the operating environment is almost identical to the one where this protocol would be deployed. It should also be noted that since this protocol is designed to be deployed between two adjacent PEs connected by a physical link, it is not possible to misdirect or inject traffic without compromising the PW transport link itself.
[RFC6478]中讨论的安全注意事项对于本文档中描述的机制是足够的，因为操作环境与部署此协议的环境几乎相同。还应注意的是，由于该协议被设计为部署在通过物理链路连接的两个相邻PE之间，因此不可能在不损害PW传输链路本身的情况下误导或注入流量。
The registries in this section have been created or updated as appropriate in the "Pseudowire Name Spaces (PWE3)" registry or the "Generic Associated Channel (G-ACh) Parameters" registry. For the allocation ranges designated as "vendor-proprietary extensions", the respective IANA registry contains the vendor name in brackets at the end of the Description field.
本节中的注册表已在“伪线名称空间（PWE3）”注册表或“通用关联通道（G-ACh）参数”注册表中创建或更新。对于指定为“供应商专有扩展”的分配范围，相应的IANA注册表在描述字段末尾的括号中包含供应商名称。
IANA has set up the "PW Status Refresh Reduction Control Messages" registry. This registry contains 8-bit values. Type values 1 and 2 are defined in this document. Type values 3 through 64 and 128 through 254 are to be assigned by IANA using the "Expert Review" policy defined in [RFC8126]. Type values 65 through 127, 0, and 255 are to be allocated using the "IETF Review" policy defined in [RFC8126].
IANA已经建立了“PW状态刷新减少控制消息”注册表。此注册表包含8位值。本文档中定义了类型值1和2。IANA将使用[RFC8126]中定义的“专家评审”政策分配类型值3至64和128至254。使用[RFC8126]中定义的“IETF审查”策略分配类型值65到127、0和255。
The Type values are assigned as follows:
类型值的分配如下所示：
Type Message Description
---- ------------------------
0x01 Notification message
0x02 PW Configuration Message
Type Message Description
---- ------------------------
0x01 Notification message
0x02 PW Configuration Message
IANA has set up the "PW Status Refresh Reduction Configuration Message Sub-TLVs" registry. This registry contains 8-bit values. Type values 1 through 3 are defined in this document. Type values 4 through 64 and 128 through 254 are to be assigned by IANA using the "Expert Review" policy defined in [RFC8126]. Type values 65 through 127, 0, and 255 are to be allocated using the "IETF Review" policy defined in [RFC8126].
IANA已设置“PW状态刷新减少配置消息子TLVs”注册表。此注册表包含8位值。本文档中定义了类型值1到3。IANA将使用[RFC8126]中定义的“专家评审”策略分配类型值4至64和128至254。使用[RFC8126]中定义的“IETF审查”策略分配类型值65到127、0和255。
The Type values are assigned as follows:
类型值的分配如下所示：
Sub-TLV Type Description
------------ -----------------------
0x01 MPLS-TP Tunnel ID
0x02 PW ID Configured List
0x03 PW ID Unconfigured List
Sub-TLV Type Description
------------ -----------------------
0x01 MPLS-TP Tunnel ID
0x02 PW ID Configured List
0x03 PW ID Unconfigured List
IANA has set up the "PW Status Refresh Reduction Notification Codes" registry. This registry contains 32-bit values. Type values 0 through 7 are defined in this document. Type values 8 through 65536 and 134,217,729 through 4,294,967,294 are to be assigned by IANA using the "Expert Review" policy defined in [RFC8126]. Type values 65537 through 134,217,728, 0, and 4,294,967,295 are to be allocated using the "IETF Review" policy defined in [RFC8126].
IANA已建立“PW状态刷新减少通知代码”注册表。此注册表包含32位值。本文档中定义了类型值0到7。IANA使用[RFC8126]中定义的“专家评审”政策分配类型值8至65536和134217729至4294967294。使用[RFC8126]中定义的“IETF审查”策略分配类型值65537到134217728、0和4294967295。
For each value assigned, IANA should also track whether the value constitutes an error as described in Section 5.1. When values are assigned by IETF Review, the settings in the "Error?" column must be documented in the RFC that requests the allocation. For "Expert Review" assignments, the settings in the "Error?" column must be made clear by the requester at the time of assignment.
对于分配的每个值，IANA还应跟踪该值是否构成第5.1节所述的错误。当IETF Review分配值时，“错误”列中的设置必须记录在请求分配的RFC中。对于“专家评审”任务，“错误？”列中的设置必须在任务分配时由请求者明确。
The Type values are assigned as follows:
类型值的分配如下所示：
Code Error? Description
---------- ------ ------------------------------
0x00000000 No Null Notification
0x00000001 No PW configuration mismatch
0x00000002 Yes PW Configuration TLV conflict
0x00000003 No Unknown TLV (U-Bit=1)
0x00000004 Yes Unknown TLV (U-Bit=0)
0x00000005 No Unknown Message Type
0x00000006 No PW configuration not supported
0x00000007 Yes Unacknowledged control message
Code Error? Description
---------- ------ ------------------------------
0x00000000 No Null Notification
0x00000001 No PW configuration mismatch
0x00000002 Yes PW Configuration TLV conflict
0x00000003 No Unknown TLV (U-Bit=1)
0x00000004 Yes Unknown TLV (U-Bit=0)
0x00000005 No Unknown Message Type
0x00000006 No PW configuration not supported
0x00000007 Yes Unacknowledged control message
IANA has set up the "PW Status Refresh Reduction Message Flags" registry. This is an 8-bit registry, with the first two most significant bits allocated by this document as follows:
IANA已设置“PW状态刷新减少消息标志”注册表。这是一个8位注册表，本文档分配的前两个最高有效位如下：
Bit Position Name Description
------------ ---- ----------------------
0 U Unknown flag bit
1 C Configuration flag bit
Bit Position Name Description
------------ ---- ----------------------
0 U Unknown flag bit
1 C Configuration flag bit
The remaining bits are to be allocated using the "IETF Review" policy defined in [RFC8126].
剩余比特将使用[RFC8126]中定义的“IETF审查”策略进行分配。
IANA maintains a registry called "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)". IANA has allocated a new value as follows:
IANA维护一个名为“MPLS通用关联通道（G-ACh）类型（包括伪线关联通道类型）”的注册表。IANA分配了一个新值，如下所示：
Value Description Reference
----- --------------------------- ---------
0x29 PW Status Refresh Reduction RFC 8237
Value Description Reference
----- --------------------------- ---------
0x29 PW Status Refresh Reduction RFC 8237
In all cases of review by the Designated Expert (DE) described here, the DE is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and to verify that the document is permanently and publicly available. The DE is also expected to check that the clarity of purpose and use of the requested code points fit the general architecture and intended purpose of the respective message or TLV. Lastly, the DE should check that any assignment does not duplicate or conflict with work that is active or already published within the IETF.
在此处所述指定专家（DE）审查的所有情况下，DE应确定是否存在[RFC8126]中所述的适当文件（规范），并验证文件是否永久公开。DE还应检查所请求代码点的用途和使用是否符合各报文或TLV的一般架构和预期用途。最后，DE应检查任何作业是否与IETF中正在进行或已发布的作业重复或冲突。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <https://www.rfc-editor.org/info/rfc6370>.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 6370，DOI 10.17487/RFC6370，2011年9月<https://www.rfc-editor.org/info/rfc6370>.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, DOI 10.17487/RFC6478, May 2012, <https://www.rfc-editor.org/info/rfc6478>.
[RFC6478]Martini，L.，Swallow，G.，Heron，G.，和M.Bocci，“静态伪线的伪线状态”，RFC 6478，DOI 10.17487/RFC6478，2012年5月<https://www.rfc-editor.org/info/rfc6478>.
[RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077]Martini，L.，Ed.，和G.Heron，Ed.，“使用标签分发协议（LDP）的伪线设置和维护”，STD 84，RFC 8077，DOI 10.17487/RFC8077，2017年2月<https://www.rfc-editor.org/info/rfc8077>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 5586，DOI 10.17487/RFC55862009年6月<https://www.rfc-editor.org/info/rfc5586>.
Authors' Addresses
作者地址
Luca Martini Monoski LLC
卢卡·马丁尼·莫诺斯基有限责任公司
Email: lmartini@monoski.com
Email: lmartini@monoski.com
George Swallow Southend Technical Center
乔治·斯沃恩·索森德技术中心
Email: swallow.ietf@gmail.com
Email: swallow.ietf@gmail.com
Elisa Bellagamba Ericsson EAB Torshamnsgatan 48 16480, Stockholm Sweden
Elisa Bellagamba Ericsson EAB Torshamnsgatan 48 16480，瑞典斯德哥尔摩
Email: elisa.bellagamba@gmail.com
Email: elisa.bellagamba@gmail.com