Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 7275 S. Salam
Category: Standards Track A. Sajassi
ISSN: 2070-1721 Cisco
M. Bocci
Alcatel-Lucent
S. Matsushima
Softbank Telecom
T. Nadeau
Brocade
June 2014
Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 7275 S. Salam
Category: Standards Track A. Sajassi
ISSN: 2070-1721 Cisco
M. Bocci
Alcatel-Lucent
S. Matsushima
Softbank Telecom
T. Nadeau
Brocade
June 2014
Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy
用于第2层虚拟专用网络（L2VPN）提供商边缘（PE）冗余的机箱间通信协议
Abstract
摘要
This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.
本文档指定了机箱间通信协议（ICCP），该协议为虚拟专用线服务（VPWS）和虚拟专用局域网服务（VPLS）应用程序启用提供商边缘（PE）设备冗余。该协议在一组两个或多个PE内运行，形成一个冗余组，以便在系统之间同步数据。它容纳多机箱连接电路冗余机制以及伪线冗余机制。
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/rfc7275.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7275.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................5
2. Specification of Requirements ...................................5
3. ICCP Overview ...................................................5
3.1. Redundancy Model and Topology ..............................5
3.2. ICCP Interconnect Scenarios ................................7
3.2.1. Co-located Dedicated Interconnect ...................7
3.2.2. Co-located Shared Interconnect ......................8
3.2.3. Geo-redundant Dedicated Interconnect ................8
3.2.4. Geo-redundant Shared Interconnect ...................9
3.3. ICCP Requirements .........................................10
4. ICC LDP Protocol Extension Specification .......................11
4.1. LDP ICCP Capability Advertisement .........................12
4.2. RG Membership Management ..................................12
4.2.1. ICCP Connection State Machine ......................13
4.3. Redundant Object Identification ...........................17
4.4. Application Connection Management .........................17
4.4.1. Application Versioning .............................18
4.4.2. Application Connection State Machine ...............19
4.5. Application Data Transfer .................................22
4.6. Dedicated Redundancy Group LDP Session ....................22
5. ICCP PE Node Failure / Isolation Detection Mechanism ...........22
6. ICCP Message Formats ...........................................23
6.1. Encoding ICC into LDP Messages ............................23
6.1.1. ICC Header .........................................24
6.1.2. ICC Parameter Encoding .............................26
6.1.3. Redundant Object Identifier Encoding ...............27
6.2. RG Connect Message ........................................27
6.2.1. ICC Sender Name TLV ................................28
6.3. RG Disconnect Message .....................................29
6.4. RG Notification Message ...................................31
6.4.1. Notification Message TLVs ..........................32
6.5. RG Application Data Message ...............................35
7. Application TLVs ...............................................35
7.1. Pseudowire Redundancy (PW-RED) Application TLVs ...........35
7.1.1. PW-RED Connect TLV .................................36
7.1.2. PW-RED Disconnect TLV ..............................37
7.1.2.1. PW-RED Disconnect Cause TLV ...............38
7.1.3. PW-RED Config TLV ..................................39
7.1.3.1. Service Name TLV ..........................41
7.1.3.2. PW ID TLV .................................42
7.1.3.3. Generalized PW ID TLV .....................43
7.1.4. PW-RED State TLV ...................................44
7.1.5. PW-RED Synchronization Request TLV .................45
7.1.6. PW-RED Synchronization Data TLV ....................46
1. Introduction ....................................................5
2. Specification of Requirements ...................................5
3. ICCP Overview ...................................................5
3.1. Redundancy Model and Topology ..............................5
3.2. ICCP Interconnect Scenarios ................................7
3.2.1. Co-located Dedicated Interconnect ...................7
3.2.2. Co-located Shared Interconnect ......................8
3.2.3. Geo-redundant Dedicated Interconnect ................8
3.2.4. Geo-redundant Shared Interconnect ...................9
3.3. ICCP Requirements .........................................10
4. ICC LDP Protocol Extension Specification .......................11
4.1. LDP ICCP Capability Advertisement .........................12
4.2. RG Membership Management ..................................12
4.2.1. ICCP Connection State Machine ......................13
4.3. Redundant Object Identification ...........................17
4.4. Application Connection Management .........................17
4.4.1. Application Versioning .............................18
4.4.2. Application Connection State Machine ...............19
4.5. Application Data Transfer .................................22
4.6. Dedicated Redundancy Group LDP Session ....................22
5. ICCP PE Node Failure / Isolation Detection Mechanism ...........22
6. ICCP Message Formats ...........................................23
6.1. Encoding ICC into LDP Messages ............................23
6.1.1. ICC Header .........................................24
6.1.2. ICC Parameter Encoding .............................26
6.1.3. Redundant Object Identifier Encoding ...............27
6.2. RG Connect Message ........................................27
6.2.1. ICC Sender Name TLV ................................28
6.3. RG Disconnect Message .....................................29
6.4. RG Notification Message ...................................31
6.4.1. Notification Message TLVs ..........................32
6.5. RG Application Data Message ...............................35
7. Application TLVs ...............................................35
7.1. Pseudowire Redundancy (PW-RED) Application TLVs ...........35
7.1.1. PW-RED Connect TLV .................................36
7.1.2. PW-RED Disconnect TLV ..............................37
7.1.2.1. PW-RED Disconnect Cause TLV ...............38
7.1.3. PW-RED Config TLV ..................................39
7.1.3.1. Service Name TLV ..........................41
7.1.3.2. PW ID TLV .................................42
7.1.3.3. Generalized PW ID TLV .....................43
7.1.4. PW-RED State TLV ...................................44
7.1.5. PW-RED Synchronization Request TLV .................45
7.1.6. PW-RED Synchronization Data TLV ....................46
7.2. Multi-Chassis LACP (mLACP) Application TLVs ...............48
7.2.1. mLACP Connect TLV ..................................48
7.2.2. mLACP Disconnect TLV ...............................49
7.2.2.1. mLACP Disconnect Cause TLV ................50
7.2.3. mLACP System Config TLV ............................51
7.2.4. mLACP Aggregator Config TLV ........................52
7.2.5. mLACP Port Config TLV ..............................54
7.2.6. mLACP Port Priority TLV ............................56
7.2.7. mLACP Port State TLV ...............................58
7.2.8. mLACP Aggregator State TLV .........................60
7.2.9. mLACP Synchronization Request TLV ..................61
7.2.10. mLACP Synchronization Data TLV ....................63
8. LDP Capability Negotiation .....................................65
9. Client Applications ............................................66
9.1. Pseudowire Redundancy Application Procedures ..............66
9.1.1. Initial Setup ......................................66
9.1.2. Pseudowire Configuration Synchronization ...........66
9.1.3. Pseudowire Status Synchronization ..................67
9.1.3.1. Independent Mode ..........................69
9.1.3.2. Master/Slave Mode .........................69
9.1.4. PE Node Failure or Isolation .......................70
9.2. Attachment Circuit Redundancy Application Procedures ......70
9.2.1. Common AC Procedures ...............................70
9.2.1.1. AC Failure ................................70
9.2.1.2. Remote PE Node Failure or Isolation .......70
9.2.1.3. Local PE Isolation ........................71
9.2.1.4. Determining Pseudowire State ..............71
9.2.2. Multi-Chassis LACP (mLACP) Application Procedures ..72
9.2.2.1. Initial Setup .............................72
9.2.2.2. mLACP Aggregator and Port Configuration ...74
9.2.2.3. mLACP Aggregator and Port Status
Synchronization ...........................75
9.2.2.4. Failure and Recovery ......................77
10. Security Considerations .......................................78
11. Manageability Considerations ..................................79
12. IANA Considerations ...........................................79
12.1. Message Type Name Space ..................................79
12.2. TLV Type Name Space ......................................79
12.3. ICC RG Parameter Type Space ..............................80
12.4. Status Code Name Space ...................................81
13. Acknowledgments ...............................................81
14. References ....................................................81
14.1. Normative References .....................................81
14.2. Informative References ...................................82
7.2. Multi-Chassis LACP (mLACP) Application TLVs ...............48
7.2.1. mLACP Connect TLV ..................................48
7.2.2. mLACP Disconnect TLV ...............................49
7.2.2.1. mLACP Disconnect Cause TLV ................50
7.2.3. mLACP System Config TLV ............................51
7.2.4. mLACP Aggregator Config TLV ........................52
7.2.5. mLACP Port Config TLV ..............................54
7.2.6. mLACP Port Priority TLV ............................56
7.2.7. mLACP Port State TLV ...............................58
7.2.8. mLACP Aggregator State TLV .........................60
7.2.9. mLACP Synchronization Request TLV ..................61
7.2.10. mLACP Synchronization Data TLV ....................63
8. LDP Capability Negotiation .....................................65
9. Client Applications ............................................66
9.1. Pseudowire Redundancy Application Procedures ..............66
9.1.1. Initial Setup ......................................66
9.1.2. Pseudowire Configuration Synchronization ...........66
9.1.3. Pseudowire Status Synchronization ..................67
9.1.3.1. Independent Mode ..........................69
9.1.3.2. Master/Slave Mode .........................69
9.1.4. PE Node Failure or Isolation .......................70
9.2. Attachment Circuit Redundancy Application Procedures ......70
9.2.1. Common AC Procedures ...............................70
9.2.1.1. AC Failure ................................70
9.2.1.2. Remote PE Node Failure or Isolation .......70
9.2.1.3. Local PE Isolation ........................71
9.2.1.4. Determining Pseudowire State ..............71
9.2.2. Multi-Chassis LACP (mLACP) Application Procedures ..72
9.2.2.1. Initial Setup .............................72
9.2.2.2. mLACP Aggregator and Port Configuration ...74
9.2.2.3. mLACP Aggregator and Port Status
Synchronization ...........................75
9.2.2.4. Failure and Recovery ......................77
10. Security Considerations .......................................78
11. Manageability Considerations ..................................79
12. IANA Considerations ...........................................79
12.1. Message Type Name Space ..................................79
12.2. TLV Type Name Space ......................................79
12.3. ICC RG Parameter Type Space ..............................80
12.4. Status Code Name Space ...................................81
13. Acknowledgments ...............................................81
14. References ....................................................81
14.1. Normative References .....................................81
14.2. Informative References ...................................82
Network availability is a critical metric for service providers, as it has a direct bearing on their profitability. Outages translate not only to lost revenue but also to potential penalties mandated by contractual agreements with customers running mission-critical applications that require tight Service Level Agreements (SLAs). This is true for any carrier network, and networks employing Layer 2 Virtual Private Network (L2VPN) technology are no exception. A high degree of network availability can be achieved by employing intra-and inter-chassis redundancy mechanisms. The focus of this document is on the latter. This document defines an Inter-Chassis Communication Protocol (ICCP) that allows synchronization of state and configuration data between a set of two or more Provider Edge nodes (PEs) forming a Redundancy Group (RG). The protocol supports multi-chassis redundancy mechanisms that can be employed on either the attachment circuits or pseudowires (PWs). A formal definition of the term "chassis" can be found in [RFC2922]. For the purpose of this document, a chassis is an L2VPN PE node.
网络可用性是服务提供商的一个关键指标，因为它直接关系到他们的盈利能力。停机不仅会导致收入损失，还会导致与运行需要严格服务级别协议（SLA）的任务关键型应用程序的客户签订的合同协议规定的潜在处罚。任何运营商网络都是如此，采用第二层虚拟专用网（L2VPN）技术的网络也不例外。通过采用机箱内和机箱间冗余机制，可以实现高度的网络可用性。本文件的重点是后者。本文档定义了机箱间通信协议（ICCP），该协议允许在构成冗余组（RG）的两个或多个提供商边缘节点（PE）之间同步状态和配置数据。该协议支持多机箱冗余机制，可用于连接电路或伪线（PWs）。术语“机箱”的正式定义见[RFC2922]。在本文档中，机箱是L2VPN PE节点。
This document assumes that it is normal to run the Label Distribution Protocol (LDP) between the PEs in the RG, and that LDP components will in any case be present on the PEs to establish and maintain pseudowires. Therefore, ICCP is built as a secondary protocol running within LDP and taking advantage of the LDP session mechanisms as well as the underlying TCP transport mechanisms and TCP-based security mechanisms already necessary for LDP operation.
本文件假设在RG中的PEs之间运行标签分发协议（LDP）是正常的，并且LDP组件在任何情况下都将出现在PEs上，以建立和维护伪线。因此，ICCP被构建为在LDP内运行的二级协议，并利用LDP会话机制以及LDP运行所必需的底层TCP传输机制和基于TCP的安全机制。
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]中所述进行解释。
The focus of this document is on PE node redundancy. It is assumed that a set of two or more PE nodes are designated by the operator to form an RG. Members of an RG fall under a single administration (e.g., service provider) and employ a common redundancy mechanism towards the access (attachment circuits or access pseudowires) and/or towards the core (pseudowires) for any given service instance. It is possible, however, for members of an RG to make use of disparate redundancy mechanisms for disjoint services. The PE devices may be offering any type of L2VPN service, i.e., Virtual Private Wire Service (VPWS) or Virtual Private LAN Service (VPLS). As a matter of
本文档的重点是PE节点冗余。假设操作员指定一组两个或多个PE节点以形成RG。RG的成员属于单一管理（例如，服务提供商），并对任何给定服务实例的访问（连接电路或访问伪线）和/或核心（伪线）采用公共冗余机制。然而，RG的成员可以为不相交的服务使用不同的冗余机制。PE设备可以提供任何类型的L2VPN服务，即虚拟专用线服务（VPWS）或虚拟专用LAN服务（VPLS）。实际上
fact, the use of ICCP may even be applicable for Layer 3 service redundancy, but this is considered to be outside the scope of this document.
事实上，ICCP的使用甚至可能适用于第3层服务冗余，但这被认为超出了本文档的范围。
The PEs in an RG offer multi-homed connectivity to either individual devices (e.g., Customer Edge (CE), Digital Subscriber Line Access Multiplexer (DSLAM)) or entire networks (e.g., access network). Figure 1 below depicts the model.
RG中的PEs提供到单个设备（例如，客户边缘（CE）、数字用户线接入多路复用器（DSLAM））或整个网络（例如，接入网络）的多宿连接。下面的图1描述了该模型。
+=================+
| |
Multi-homed +----+ | +-----+ |
Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->|
| |--+ -|--| ||<------|---Pseudowire-->|
+----+ | / | +-----+ |
| / | || |
|/ | || ICCP |--> Towards Core
+-------------+ / | || |
| | /| | +-----+ |
| Access |/ +----|--| PE2 ||<------|---Pseudowire-->|
| Network |-------|--| ||<------|---Pseudowire-->|
| | | +-----+ |
| | | |
+-------------+ | Redundancy |
^ | Group |
| +=================+
|
Multi-homed Network
+=================+
| |
Multi-homed +----+ | +-----+ |
Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->|
| |--+ -|--| ||<------|---Pseudowire-->|
+----+ | / | +-----+ |
| / | || |
|/ | || ICCP |--> Towards Core
+-------------+ / | || |
| | /| | +-----+ |
| Access |/ +----|--| PE2 ||<------|---Pseudowire-->|
| Network |-------|--| ||<------|---Pseudowire-->|
| | | +-----+ |
| | | |
+-------------+ | Redundancy |
^ | Group |
| +=================+
|
Multi-homed Network
Figure 1: Generic Multi-Chassis Redundancy Model
图1：通用多机箱冗余模型
In the topology shown in Figure 1, the redundancy mechanism employed towards the access node/network can be one of a multitude of technologies, e.g., it could be IEEE 802.1AX Link Aggregation Groups with the Link Aggregation Control Protocol (LACP) or Synchronous Optical Network Automatic Protection Switching (SONET APS). The specifics of the mechanism are outside the scope of this document. However, it is assumed that the PEs in the RG are required to communicate with each other in order for the access redundancy mechanism to operate correctly. As such, it is required that an inter-chassis communication protocol among the PEs in the RG be run in order to synchronize configuration and/or running state data.
在图1所示的拓扑中，用于接入节点/网络的冗余机制可以是多种技术中的一种，例如，它可以是具有链路聚合控制协议（LACP）的IEEE 802.1AX链路聚合组或同步光网络自动保护交换（SONET APS）。该机制的具体内容超出了本文件的范围。然而，假设RG中的PEs需要彼此通信，以便接入冗余机制正确工作。因此，需要运行RG中PEs之间的机箱间通信协议，以便同步配置和/或运行状态数据。
Furthermore, the presence of the inter-chassis communication channel allows simplification of the pseudowire redundancy mechanism. This is primarily because it allows the PEs within an RG to run some arbitration algorithm to elect which pseudowire(s) should be in active or standby mode for a given service instance. The PEs can
此外，机箱间通信信道的存在允许简化伪线冗余机制。这主要是因为它允许RG内的PEs运行一些仲裁算法，以选择给定服务实例的伪线应处于活动或备用模式。PEs可以
then advertise the outcome of the arbitration to the remote-end PE(s), as opposed to having to embed a handshake procedure into the pseudowire redundancy status communication mechanism as well as every other possible Layer 2 status communication mechanism.
然后将仲裁结果通告给远程终端PE，而不是必须将握手过程嵌入到伪线冗余状态通信机制以及每一个其他可能的第2层状态通信机制中。
When referring to "interconnect" in this section, we are concerned with the links or networks over which Inter-Chassis Communication Protocol messages are transported, and not normal data traffic between PEs. The PEs that are members of an RG may be either physically co-located or geo-redundant. Furthermore, the physical interconnect between the PEs over which ICCP is to run may comprise either dedicated back-to-back links or a shared connection through the packet switched network (PSN), e.g., MPLS core network. This gives rise to a matrix of four interconnect scenarios, as described in the following subsections.
在本节中提到“互连”时，我们关注的是机箱间通信协议消息传输的链路或网络，而不是PEs之间的正常数据通信。作为RG成员的PEs可以是物理上同一位置的，也可以是地理上冗余的。此外，要在其上运行ICCP的PEs之间的物理互连可以包括专用背靠背链路或通过分组交换网络（PSN）（例如MPLS核心网络）的共享连接。这将产生一个由四种互连方案组成的矩阵，如下小节所述。
In this scenario, the PEs within an RG are co-located in the same physical location, e.g., point of presence (POP) or central office (CO). Furthermore, dedicated links provide the interconnect for ICCP among the PEs.
在这种情况下，RG内的PE位于同一物理位置，例如存在点（POP）或中央办公室（co）。此外，专用链路为PEs之间的ICCP提供互连。
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
| || | | |
| || ICCP | | Core |
| || | | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
| | | |
+=================+ +-----------------+
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
| || | | |
| || ICCP | | Core |
| || | | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
| | | |
+=================+ +-----------------+
Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario
图2:ICCP共址PEs专用互连场景
Given that the PEs are connected back-to-back in this case, it is possible to rely on Layer 2 redundancy mechanisms to guarantee the robustness of the ICCP interconnect. For example, if the
鉴于PEs在这种情况下是背靠背连接的，因此可以依靠第2层冗余机制来保证ICCP互连的健壮性。例如，如果
interconnect comprises IEEE 802.3 Ethernet links, it is possible to provide link redundancy by means of IEEE 802.1AX Link Aggregation Groups.
互连包括IEEE 802.3以太网链路，可以通过IEEE 802.1AX链路聚合组提供链路冗余。
In this scenario, the PEs within an RG are co-located in the same physical location (POP, CO). However, unlike the previous scenario, there are no dedicated links between the PEs. The interconnect for ICCP is provided through the core network to which the PEs are connected. Figure 3 depicts this model.
在这种情况下，RG内的PE位于同一物理位置（POP，co）。但是，与前面的场景不同，PEs之间没有专用链接。ICCP的互连通过PEs连接的核心网络提供。图3描述了这个模型。
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
| | | || |
| | | || Core |
| | | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
| | | |
+=================+ +-----------------+
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
| | | || |
| | | || Core |
| | | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
| | | |
+=================+ +-----------------+
Figure 3: ICCP Co-located PEs Shared Interconnect Scenario
图3:ICCP共址PEs共享互连场景
Given that the PEs in the RG are connected over the PSN, PSN Layer mechanisms can be leveraged to ensure the resiliency of the interconnect against connectivity failures. For example, it is possible to employ RSVP Label Switched Paths (LSPs) with Fast Reroute (FRR) and/or end-to-end backup LSPs.
鉴于RG中的PE通过PSN连接，可以利用PSN层机制确保互连的弹性，以防连接故障。例如，可以使用具有快速重路由（FRR）和/或端到端备份LSP的RSVP标签交换路径（LSP）。
In this variation, the PEs within an RG are located in different physical locations to provide geographic redundancy. This may be desirable, for example, to protect against natural disasters or the like. A dedicated interconnect is provided to link the PEs. This is a costly option, especially when considering the possibility of providing multiple such links for interconnect robustness. The resiliency mechanisms for the interconnect are similar to those highlighted in the co-located interconnect counterpart.
在此变体中，RG内的PE位于不同的物理位置，以提供地理冗余。例如，为了防止自然灾害等，这可能是可取的。提供专用互连以连接PEs。这是一个昂贵的选择，尤其是考虑到提供多个这样的链路以实现互连健壮性的可能性时。互连的弹性机制类似于位于同一位置的互连对应物中突出显示的机制。
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
+=====||==========+ | |
|| ICCP | Core |
+=====||==========+ | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
+=====||==========+ | |
|| ICCP | Core |
+=====||==========+ | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario
图4:ICCP地理冗余PEs专用互连场景
In this scenario, the PEs of an RG are located in different physical locations and the interconnect for ICCP is provided over the PSN network to which the PEs are connected. This interconnect option is more likely to be the one used for geo-redundancy, as it is more economically appealing compared to the geo-redundant dedicated interconnect option. The resiliency mechanisms that can be employed to guarantee the robustness of the ICCP transport are PSN Layer mechanisms, as described in Section 3.2.2 above.
在这种情况下，RG的PEs位于不同的物理位置，ICCP的互连通过PEs所连接的PSN网络提供。此互连选项更有可能用于地理冗余，因为与地理冗余专用互连选项相比，它在经济上更具吸引力。可用于保证ICCP传输健壮性的弹性机制为PSN层机制，如上文第3.2.2节所述。
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
+=================+ | || |
| || Core |
+=================+ | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
+=================+ | || |
| || Core |
+=================+ | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario
图5:ICCP地理冗余PEs共享互连场景
The requirements for the Inter-Chassis Communication Protocol are as follows:
机箱间通信协议的要求如下：
i. ICCP MUST provide a control channel for communication between PEs in a Redundancy Group (RG). PE nodes may be co-located or remote (refer to Section 3.2 above). Client applications that make use of ICCP services MUST only use this channel to communicate control information and not data traffic. As such, the protocol SHOULD provide relatively low bandwidth, low delay, and highly reliable message transfer.
i. ICCP必须为冗余组（RG）中的PEs之间的通信提供控制通道。PE节点可位于同一地点或远程（参考上文第3.2节）。使用ICCP服务的客户端应用程序必须仅使用此通道来传输控制信息，而不是数据流量。因此，协议应提供相对较低的带宽、低延迟和高度可靠的消息传输。
ii. ICCP MUST accommodate multiple client applications (e.g., multi-chassis LACP, PW redundancy, SONET APS). This implies that the messages SHOULD be extensible (e.g., TLV-based), and the protocol SHOULD provide a robust application registration and versioning scheme.
二,。ICCP必须适应多个客户端应用程序（例如，多机箱LACP、PW冗余、SONET AP）。这意味着消息应该是可扩展的（例如，基于TLV），协议应该提供健壮的应用程序注册和版本控制方案。
iii. ICCP MUST provide reliable message transport and in-order delivery between nodes in an RG with secure authentication mechanisms built into the protocol. The redundancy applications that are clients of ICCP expect reliable message transfer and as such will assume that the protocol takes care of flow control and retransmissions. Furthermore, given that the applications will rely on ICCP to communicate data used to synchronize state machines on disparate nodes, it is critical that ICCP guarantees in-order message delivery. Loss of messages or out-of-sequence messages would have adverse effects on the operation of the client applications.
iii.ICCP必须在RG中的节点之间提供可靠的消息传输和有序交付，并在协议中内置安全认证机制。作为ICCP客户端的冗余应用程序期望可靠的消息传输，因此将假定该协议负责流控制和重传。此外，鉴于应用程序将依赖ICCP来传输用于在不同节点上同步状态机的数据，ICCP保证有序的消息传递至关重要。消息丢失或无序消息将对客户端应用程序的操作产生不利影响。
iv. ICCP MUST provide a common mechanism to actively monitor the health of PEs in an RG. This mechanism will be used to detect PE node failure (or isolation from the MPLS network in the case of shared interconnect) and inform the client applications. The applications require that the mechanism trigger failover according to the procedures of the redundancy protocol employed on the attachment circuit (AC) and PW. The solution SHOULD achieve sub-second detection of loss of remote node (~50-150 msec) in order to give the client applications (redundancy mechanisms) enough reaction time to achieve sub-second service restoration times.
iv.ICCP必须提供一个共同机制，以积极监测RG中PEs的健康状况。该机制将用于检测PE节点故障（或在共享互连的情况下与MPLS网络隔离），并通知客户端应用程序。应用程序要求该机制根据连接电路（AC）和PW上采用的冗余协议的程序触发故障切换。该解决方案应实现次秒的远程节点丢失检测（~50-150毫秒），以便为客户端应用程序（冗余机制）提供足够的反应时间，以实现次秒的服务恢复时间。
v. ICCP SHOULD provide asynchronous event-driven state update, independent of periodic messages, for immediate notification of client applications' state changes. In other words, the transmission of messages carrying application data SHOULD be on-demand rather than timer-based to minimize inter-chassis state synchronization delay.
v. ICCP应提供异步事件驱动的状态更新，独立于定期消息，以便立即通知客户端应用程序的状态更改。换句话说，承载应用程序数据的消息的传输应该是按需的，而不是基于计时器的，以最小化机箱间状态同步延迟。
vi. ICCP MUST accommodate multi-link and multi-hop interconnects between nodes. When the devices within an RG are located in different physical locations, the physical interconnect between them will comprise a network rather than a link. As such, ICCP MUST accommodate the case where the interconnect involves multiple hops. Furthermore, it is possible to have multiple (redundant) paths or interconnects between a given pair of devices. This is true for both the co-located and geo-redundant scenarios. ICCP MUST handle this as well.
vi.ICCP必须适应节点之间的多链路和多跳互连。当RG内的设备位于不同的物理位置时，它们之间的物理互连将包括网络而不是链路。因此，ICCP必须适应互连涉及多跳的情况。此外，在给定的一对设备之间可能有多条（冗余）路径或互连。这对于同一地点和地理冗余场景都是如此。ICCP也必须处理这个问题。
vii. ICCP MUST ensure transport security between devices in an RG. This is especially important in the scenario where the members of an RG are located in different physical locations and connected over a shared network (e.g., PSN). In particular, ICCP MUST NOT accept connections arbitrarily from any device; otherwise, the state of client applications might be compromised. Furthermore, even if an ICCP connection request appears to come from an eligible device, its source address may have been spoofed. Therefore, some means of preventing source address spoofing MUST be in place.
七,。ICCP必须确保RG中设备之间的传输安全。这在RG成员位于不同物理位置并通过共享网络（例如，PSN）连接的场景中尤其重要。特别是，ICCP不得任意接受来自任何设备的连接；否则，客户端应用程序的状态可能会受到影响。此外，即使ICCP连接请求似乎来自合格的设备，其源地址也可能被伪造。因此，必须采取一些措施防止源地址欺骗。
viii. ICCP MUST allow the operator to statically configure members of an RG. Auto-discovery may be considered in the future.
八,。ICCP必须允许操作员静态配置RG的成员。将来可能会考虑自动发现。
ix. ICCP SHOULD allow for flexible RG membership. It is expected that only two nodes in an RG will cover most of the redundancy applications for common deployments. ICCP SHOULD NOT preclude supporting more than two nodes in an RG by virtue of design. Furthermore, ICCP MUST allow a single node to be a member of multiple RGs simultaneously.
ICCP应允许灵活的RG成员资格。预计一个RG中只有两个节点将覆盖大多数通用部署的冗余应用程序。ICCP不应排除通过设计支持RG中两个以上的节点。此外，ICCP必须允许单个节点同时成为多个RG的成员。
To address the requirements identified in the previous section, ICCP is modeled to comprise three layers:
为了满足上一节中确定的需求，ICCP建模为包括三层：
i. Application Layer: This provides the interface to the various redundancy applications that make use of the services of ICCP. ICCP is concerned with defining common connection management procedures and the formats of the messages exchanged at this layer; however, beyond that, it does not impose any restrictions
i. 应用层：它为使用ICCP服务的各种冗余应用程序提供接口。ICCP负责定义公共连接管理过程和在该层交换的消息格式；然而，除此之外，它没有施加任何限制
on the procedures or state machines of the clients, as these are deemed application specific and lie outside the scope of ICCP. This guarantees implementation interoperability without placing any unnecessary constraints on internal design specifics.
在客户的程序或状态机上，因为这些程序或状态机被视为特定于应用程序，并且不属于ICCP的范围。这保证了实现的互操作性，而不会对内部设计细节施加任何不必要的约束。
ii. Inter-Chassis Communication (ICC) Layer: This layer implements the common set of services that ICCP offers to the client applications. It handles protocol versioning, RG membership, Redundant Object identification, PE node identification, and ICCP connection management.
二,。机箱间通信（ICC）层：该层实现ICCP向客户端应用程序提供的公共服务集。它处理协议版本控制、RG成员资格、冗余对象标识、PE节点标识和ICCP连接管理。
iii. Transport Layer: This layer provides the actual ICCP message transport. It is responsible for addressing, route resolution, flow control, reliable and in-order message delivery, connectivity resiliency/redundancy, and, finally, PE node failure detection. The Transport layer may differ, depending on the Physical Layer of the interconnect.
三、传输层：该层提供实际的ICCP报文传输。它负责寻址、路由解析、流控制、可靠有序的消息传递、连接弹性/冗余，以及PE节点故障检测。传输层可能不同，这取决于互连的物理层。
When an RG is enabled on a particular PE, an LDP session to every remote PE in that RG MUST be created, if one does not already exist. The capability of supporting ICCP MUST then be advertised to all of those LDP peers in that RG. This is achieved by using the methods described in [RFC5561] and advertising the "ICCP capability TLV". If an LDP peer supports the dynamic capability advertisement, this can be done by sending a new capability message with the S-bit set for the "ICCP capability TLV" when the first RG is enabled on the PE. If the peer does not support dynamic capability advertisements, then the "ICCP TLV" MUST be included in the LDP initialization procedures in the capability parameter [RFC5561].
当在特定PE上启用RG时，必须创建到该RG中每个远程PE的LDP会话（如果还不存在）。然后，必须向该RG中的所有LDP对等方公布支持ICCP的能力。这是通过使用[RFC5561]中描述的方法并宣传“ICCP能力TLV”实现的。如果LDP对等方支持动态能力通告，则当PE上启用第一个RG时，可通过发送新的能力消息，其中S位设置为“ICCP能力TLV”。如果对等方不支持动态能力播发，则“ICCP TLV”必须包含在LDP初始化过程中的能力参数[RFC5561]中。
ICCP defines a mechanism that enables PE nodes to manage their RG membership. When a PE is configured to be a member of an RG, it will first advertise the ICCP capability to its peers. Subsequently, the PE sends an "RG Connect" message to the peers that have also advertised ICCP capability. The PE then waits for the peers to send their own "RG Connect" messages, if they haven't done so already. For a given RG, the ICCP connection between two devices is considered to be operational only when both devices have sent and received ICCP "RG Connect" messages for that RG.
ICCP定义了一种机制，使PE节点能够管理其RG成员资格。当PE被配置为RG的成员时，它将首先向其对等方公布ICCP功能。随后，PE将“RG Connect”消息发送给也已公布ICCP能力的对等方。PE然后等待对等方发送他们自己的“RG Connect”消息，如果他们还没有这样做的话。对于给定的RG，只有当两个设备都已发送和接收该RG的ICCP“RG Connect”消息时，两个设备之间的ICCP连接才被认为是可操作的。
If a PE that has sent a particular "RG Connect" message doesn't receive a corresponding RG Connect (or a Notification message rejecting the connection) from a destination, it will remain in a state of expecting the corresponding "RG Connect" message (or
如果发送特定“RG Connect”消息的PE没有从目标接收到相应的RG Connect（或拒绝连接的通知消息），则其将保持预期相应“RG Connect”消息的状态（或
Notification message). The RG will not become operational until the corresponding "RG Connect" message has been received. If a PE that has sent an "RG Connect" message receives a Notification message rejecting the connection, with a NAK TLV (Negative Acknowledgement TLV) (Section 6.4.1), it will stop attempting to bring up the ICCP connection immediately.
通知消息）。在收到相应的“RG Connect”消息之前，RG将无法运行。如果发送“RG Connect”消息的PE收到拒绝连接的通知消息，并带有NAK TLV（否定确认TLV）（第6.4.1节），则其将立即停止尝试启动ICCP连接。
A device MUST reject an incoming "RG Connect" message if at least one of the following conditions is satisfied:
如果至少满足以下条件之一，则设备必须拒绝传入的“RG Connect”消息：
i. the PE is not a member of the RG;
i. PE不是RG的成员；
ii. the maximum number of simultaneous ICCP connections that the PE can handle is exceeded.
二,。超过了PE可以处理的最大并发ICCP连接数。
Otherwise, the PE MUST bring up the connection by responding to the incoming "RG Connect" message with an appropriate RG Connect.
否则，PE必须通过使用适当的RG Connect响应传入的“RG Connect”消息来启动连接。
A PE sends an "RG Disconnect" message to tear down the ICCP connection for a given RG. This is a unilateral operation and doesn't require any acknowledgement from the other PEs. Note that the ICCP connection for an RG MUST be operational before any client application can make use of ICCP services in that RG.
PE发送“RG断开连接”消息以断开给定RG的ICCP连接。这是一个单边操作，不需要其他PE的任何确认。请注意，RG的ICCP连接必须是可操作的，然后任何客户端应用程序才能使用该RG中的ICCP服务。
A PE maintains an ICCP Connection state machine instance for every ICCP connection with a remote peer in the RG. This state machine is separate from any Application Connection state machine (Section 4.4.2). The ICCP Connection state machine reacts only to "RG Connect", "RG Disconnect", and "RG Notification" messages that do not contain any "Application TLVs". Actions and state transitions in the Application Connection state machines have no effect on the ICCP Connection state machine.
PE为与RG中远程对等方的每个ICCP连接维护一个ICCP连接状态机实例。该状态机独立于任何应用程序连接状态机（第4.4.2节）。ICCP连接状态机仅对不包含任何“应用程序TLV”的“RG Connect”、“RG Disconnect”和“RG Notification”消息作出反应。应用程序连接状态机中的操作和状态转换对ICCP连接状态机没有影响。
The ICCP Connection state machine is defined to have six states, as follows:
ICCP连接状态机定义为六种状态，如下所示：
- NONEXISTENT: This state is the starting point for the state machine. It indicates that no ICCP connection exists and that there's no LDP session established between the PEs.
- 不存在：此状态是状态机的起点。这表明不存在ICCP连接，并且PEs之间没有建立LDP会话。
- INITIALIZED: This state indicates that an LDP session exists between the PEs but LDP ICCP capability information has not yet been exchanged between them.
- 已初始化：此状态表示PEs之间存在LDP会话，但它们之间尚未交换LDP ICCP能力信息。
- CAPSENT: This state indicates that an LDP session exists between the PEs and that the local PE has advertised LDP ICCP capability to its peer.
- CAPSENT：此状态表示PEs之间存在LDP会话，并且本地PE已向其对等方公布LDP ICCP能力。
- CAPREC: This state indicates that an LDP session exists between the PEs and that the local PE has both received and advertised LDP ICCP capability from/to its peer.
- CAPREC：该状态表示PEs之间存在LDP会话，并且本地PE已从/向其对等方接收并公布LDP ICCP能力。
- CONNECTING: This state indicates that the local PE has initiated an ICCP connection to its peer and is awaiting its response.
- 正在连接：此状态表示本地PE已启动与其对等方的ICCP连接，并正在等待其响应。
- OPERATIONAL: This state indicates that the ICCP connection is operational.
- 可操作：此状态表示ICCP连接可操作。
The state transition table and state transition diagram follow.
下面是状态转换表和状态转换图。
ICCP Connection State Transition Table
ICCP连接状态转换表
STATE EVENT NEW STATE
--------------------------------------------------------------------
NONEXISTENT LDP session established INITIALIZED
STATE EVENT NEW STATE
--------------------------------------------------------------------
NONEXISTENT LDP session established INITIALIZED
INITIALIZED Transmit LDP ICCP capability CAPSENT
已初始化发送LDP ICCP能力
Receive LDP ICCP capability CAPREC Action: Transmit LDP ICCP capability
接收LDP ICCP能力CAPREC动作：发送LDP ICCP能力
LDP session torn down NONEXISTENT
自民党会议被推翻不存在
CAPSENT Receive LDP ICCP capability CAPREC
CAPSENT接收LDP ICCP能力CAPREC
LDP session torn down NONEXISTENT
自民党会议被推翻不存在
CAPREC Transmit RG Connect message CONNECTING
CAPREC传输RG连接消息连接
Receive acceptable RG Connect message OPERATIONAL Action: Transmit RG Connect message
接收可接受的RG Connect消息操作操作：发送RG Connect消息
Receive any other ICCP message CAPREC Action: Transmit NAK TLV in RG Notification message
接收任何其他ICCP消息CAPREC操作：在RG通知消息中传输NAK TLV
LDP session torn down NONEXISTENT
自民党会议被推翻不存在
CONNECTING Receive acceptable RG Connect message OPERATIONAL
连接接收可接受的RG Connect消息可操作
Receive any other ICCP message CAPREC Action: Transmit NAK TLV in RG Notification message
接收任何其他ICCP消息CAPREC操作：在RG通知消息中传输NAK TLV
LDP session torn down NONEXISTENT
自民党会议被推翻不存在
OPERATIONAL Receive acceptable RG Disconnect message CAPREC
操作接收可接受的RG断开消息CAPREC
Transmit RG Disconnect message CAPREC
发送RG断开连接信息CAPREC
LDP session torn down NONEXISTENT
自民党会议被推翻不存在
ICCP Connection State Transition Diagram
ICCP连接状态转换图
+------------+
| |
+------------------>|NONEXISTENT | LDP session torn down
| | |<--------------------------+
| +------------+ |
| LDP session | ^ LDP session |
| established | | torn down |
| V | |
| +-----------+ |
LDP | | | Tx LDP ICCP |
session| |INITIALIZED| capability |
torn | +---| |---------------+ |
down | Rx other | +-----------+ | |
| ICCP msg/ |Rx LDP ICCP | |
| Tx NAK TLV | capability/ | |
| +---+ |Tx LDP ICCP capability | |
| | | | | |
| V | V V |
| +-----------+ Rx LDP ICCP +--------+ |
+---| | capability | | |
|CAPREC |<----------------------|CAPSENT |---------->+
+---| |-------------------+ | | |
| +-----------+ | +--------+ |
| ^ ^ | |
Tx | | | | |
RG | | |Rx RG Disconnect msg | |
Connect| | | or |Rx RG Connect msg/ |
msg | | |Tx RG Disconnect msg | Tx RG Connect msg |
| | | V |
| | | +------------+ |
| | +--------------------| | |
| | |OPERATIONAL |------------>+
| | | | |
| |Rx other ICCP msg/ +------------+ |
| | Tx NAK TLV ^ |
| | | |
| +----------+ Rx RG Connect msg | |
| | |---------------------+ |
+----->|CONNECTING| |
| |----------------------------------------->+
+----------+
+------------+
| |
+------------------>|NONEXISTENT | LDP session torn down
| | |<--------------------------+
| +------------+ |
| LDP session | ^ LDP session |
| established | | torn down |
| V | |
| +-----------+ |
LDP | | | Tx LDP ICCP |
session| |INITIALIZED| capability |
torn | +---| |---------------+ |
down | Rx other | +-----------+ | |
| ICCP msg/ |Rx LDP ICCP | |
| Tx NAK TLV | capability/ | |
| +---+ |Tx LDP ICCP capability | |
| | | | | |
| V | V V |
| +-----------+ Rx LDP ICCP +--------+ |
+---| | capability | | |
|CAPREC |<----------------------|CAPSENT |---------->+
+---| |-------------------+ | | |
| +-----------+ | +--------+ |
| ^ ^ | |
Tx | | | | |
RG | | |Rx RG Disconnect msg | |
Connect| | | or |Rx RG Connect msg/ |
msg | | |Tx RG Disconnect msg | Tx RG Connect msg |
| | | V |
| | | +------------+ |
| | +--------------------| | |
| | |OPERATIONAL |------------>+
| | | | |
| |Rx other ICCP msg/ +------------+ |
| | Tx NAK TLV ^ |
| | | |
| +----------+ Rx RG Connect msg | |
| | |---------------------+ |
+----->|CONNECTING| |
| |----------------------------------------->+
+----------+
ICCP offers its client applications a uniform mechanism for identifying links, ports, forwarding constructs, and, more generally, objects (e.g., interfaces, pseudowires, VLANs) that are being protected in a redundant setup. These are referred to as Redundant Objects (ROs). An example of an RO is a multi-chassis link-aggregation group that spans two PEs. ICCP introduces a 64-bit opaque identifier to uniquely identify ROs in an RG. This identifier, referred to as the Redundant Object ID (ROID), MUST match between RG members for the protected object in question; this allows separate systems in an RG to use a common handle to reference the protected entity, irrespective of its nature (e.g., physical or virtual) and in a manner that is agnostic to implementation specifics. Client applications that need to synchronize state pertaining to a particular RO SHOULD embed the corresponding ROID in their TLVs.
ICCP为其客户机应用程序提供了一种统一的机制，用于识别链路、端口、转发结构，以及更一般地，在冗余设置中受保护的对象（例如，接口、伪线、VLAN）。这些被称为冗余对象（ROs）。RO的一个示例是跨两个PE的多机箱链路聚合组。ICCP引入64位不透明标识符，以唯一标识RG中的ROs。该标识符（称为冗余对象ID（ROID））必须在相关受保护对象的RG成员之间匹配；这允许RG中的独立系统使用公共句柄引用受保护实体，而不管其性质如何（例如，物理或虚拟），并且以与实现细节无关的方式引用。需要同步与特定RO相关的状态的客户端应用程序应在其TLV中嵌入相应的ROID。
ICCP provides a common set of procedures by which applications on one PE can connect to their counterparts on another PE, for the purpose of inter-chassis communication in the context of a given RG. The prerequisite for establishing an Application Connection is to have an operational ICCP RG connection between the two endpoints. It is assumed that the association of applications with RGs is known a priori, e.g., by means of device configuration. ICCP then sends an "Application Connect TLV" (carried in an "RG Connect" message), on behalf of each client application, to each remote PE within the RG. The client may piggyback application-specific information in that "Connect TLV", which, for example, can be used to negotiate parameters or attributes prior to bringing up the actual Application Connection. The procedures for bringing up the Application Connection are similar to those of the ICCP connection: an Application Connection between two nodes is up only when both nodes have sent and received "RG Connect" messages with the proper "Application Connect TLVs". A PE MUST send a Notification message to reject an Application Connection request if one of the following conditions is encountered:
ICCP提供了一套通用程序，通过这些程序，一个PE上的应用程序可以连接到另一个PE上的应用程序，以便在给定RG的上下文中进行机箱间通信。建立应用程序连接的先决条件是在两个端点之间具有可操作的ICCP RG连接。假定应用与RGs的关联是先验的，例如通过设备配置。然后，ICCP代表每个客户端应用程序向RG内的每个远程PE发送“Application Connect TLV”（在“RG Connect”消息中携带）。客户端可以在该“连接TLV”中携带特定于应用程序的信息，例如，该信息可用于在启动实际应用程序连接之前协商参数或属性。启动应用程序连接的过程与ICCP连接的过程类似：只有当两个节点都发送和接收了带有适当“应用程序连接TLV”的“RG Connect”消息时，两个节点之间的应用程序连接才会启动。如果遇到以下情况之一，PE必须发送通知消息以拒绝应用程序连接请求：
i. the application doesn't exist or is not configured for that RG;
i. 应用程序不存在或未为该RG配置；
ii. the Application Connection count exceeds the PE's capabilities.
二,。应用程序连接计数超过了PE的能力。
When a PE receives such a rejection notification, it MUST stop attempting to bring up the Application Connection until it receives a new Application Connection request from the remote PE. This is done by responding to the incoming "RG Connect" message (carrying an "Application Connect TLV") with an appropriate "RG Connect" message (carrying a corresponding "Application Connect TLV").
当PE收到此类拒绝通知时，它必须停止尝试启动应用程序连接，直到它从远程PE收到新的应用程序连接请求。这是通过使用适当的“RG Connect”消息（携带相应的“Application Connect TLV”）响应传入的“RG Connect”消息（携带“Application Connect TLV”）来实现的。
When an application is stopped on a device or it is no longer associated with an RG, it MUST signal ICCP to trigger sending an "Application Disconnect TLV" (in the "RG Disconnect" message). This is a unilateral notification to the other PEs within an RG and as such doesn't trigger any response.
当设备上的应用程序停止或不再与RG关联时，必须向ICCP发送信号，以触发发送“应用程序断开TLV”（在“RG断开连接”消息中）。这是对RG内其他PE的单方面通知，因此不会触发任何响应。
During Application Connection setup, a given application on one PE can negotiate with its counterpart on a peer PE the proper application version to use for communication. If no common version is agreed upon, then the Application Connection is not brought up. This is achieved through the following set of rules:
在应用程序连接设置期间，一个PE上的给定应用程序可以与其对等PE上的对应应用程序协商用于通信的正确应用程序版本。如果没有商定通用版本，则不会启动应用程序连接。这是通过以下一组规则实现的：
- If an application receives an "Application Connect TLV" with a version number that is higher than its own, it MUST send a Notification message with a "NAK TLV" indicating status code "Incompatible Protocol Version" and supplying the version that is locally supported by the PE.
- 如果应用程序接收到版本号高于其自身版本号的“应用程序连接TLV”，则它必须发送带有“NAK TLV”的通知消息，指示状态代码“不兼容协议版本”，并提供PE本地支持的版本。
- If an application receives an "Application Connect TLV" with a version number that is lower than its own, it MAY respond with an RG Connect that has an "Application Connect TLV" using the same version that was received. Alternatively, the application MAY respond with a Notification message to reject the request using the "Incompatible Protocol Version" code and supply the version that is supported. This allows an application to operate in either backwards-compatible or incompatible mode.
- 如果应用程序接收到版本号低于其自身版本号的“应用程序连接TLV”，它可能会使用与接收到的版本相同的具有“应用程序连接TLV”的RG Connect进行响应。或者，应用程序可以响应通知消息，使用“不兼容协议版本”代码拒绝请求，并提供支持的版本。这允许应用程序在向后兼容或不兼容模式下运行。
- If an application receives an "Application Connect TLV" with a version that is equal to its own, then the application MUST honor or reject the request based on whether the application is configured for the RG in question, and whether or not the Application Connection count has been exceeded.
- 如果应用程序收到版本等于其自身版本的“应用程序连接TLV”，则应用程序必须根据应用程序是否为相关RG配置以及是否已超过应用程序连接计数来接受或拒绝请求。
A PE maintains one Application Connection state machine instance per ICCP application for every ICCP connection with a remote PE in the RG. Each application's state machine reacts only to the "RG Connect", "RG Disconnect", and "RG Notification" messages that contain an "Application TLV" specifying that particular application.
对于RG中与远程PE的每个ICCP连接，PE为每个ICCP应用程序维护一个应用程序连接状态机实例。每个应用程序的状态机仅对包含指定特定应用程序的“应用程序TLV”的“RG连接”、“RG断开连接”和“RG通知”消息作出反应。
The Application Connection state machine has six states, as follows:
应用程序连接状态机有六种状态，如下所示：
- NONEXISTENT: This state indicates that the Application Connection does not exist, since there is no ICCP connection between the PEs.
- 不存在：此状态表示应用程序连接不存在，因为PEs之间没有ICCP连接。
- RESET: This state indicates that an ICCP connection is operational between the PEs but that the Application Connection has not been initialized yet or has been resent.
- 重置：此状态表示PEs之间的ICCP连接正在运行，但应用程序连接尚未初始化或已重新发送。
- CONNSENT: This state indicates that the local PE has requested initiation of an Application Connection with its peer but has not received a response yet.
- ConnSsent：此状态表示本地PE已请求启动与其对等方的应用程序连接，但尚未收到响应。
- CONNREC: This state indicates that the local PE has received a request to initiate an Application Connection from its peer but has not responded yet.
- CONNREC：此状态表示本地PE已从其对等方接收到启动应用程序连接的请求，但尚未响应。
- CONNECTING: This state indicates that the local PE has transmitted to its peer an "Application Connection" message with the A-bit set to 1 and is awaiting the peer's response.
- 连接：此状态表示本地PE已向其对等方发送A位设置为1的“应用程序连接”消息，并正在等待对等方的响应。
- OPERATIONAL: This state indicates that the Application Connection is operational.
- 可操作：此状态表示应用程序连接可操作。
The state transition table and state transition diagram follow.
下面是状态转换表和状态转换图。
ICCP Application Connection State Transition Table
ICCP应用程序连接状态转换表
STATE EVENT NEW STATE
-------------------------------------------------------------------
NONEXISTENT ICCP connection established RESET
STATE EVENT NEW STATE
-------------------------------------------------------------------
NONEXISTENT ICCP connection established RESET
RESET ICCP connection torn down NONEXISTENT
重置ICCP连接已断开不存在
Transmit Application Connect TLV CONNSENT
发送应用程序连接TLV CONNSTENT
Receive Application Connect TLV CONNREC
接收应用程序连接TLV CONNREC
Receive any other Application TLV RESET Action: Transmit NAK TLV
接收任何其他应用程序TLV重置操作：传输NAK TLV
CONNSENT Receive NAK TLV RESET
连接发送接收NAK TLV重置
Receive Application Connect TLV OPERATIONAL with A-bit=1 Action: Transmit Application Connect TLV with A-bit=1
接收应用程序连接TLV可操作且A位=1操作：发送应用程序连接TLV且A位=1
Receive any other Application TLV RESET Action: Transmit NAK TLV
接收任何其他应用程序TLV重置操作：传输NAK TLV
ICCP connection torn down NONEXISTENT
ICCP连接已断开不存在
CONNREC Transmit NAK TLV RESET
CONNREC传输NAK TLV重置
Transmit Application Connect TLV CONNECTING with A-bit=1
传输应用程序连接TLV连接A位=1
Receive Application Connect TLV CONNREC
接收应用程序连接TLV CONNREC
Receive any Application TLV except RESET Connect Action: Transmit NAK TLV
接收任何应用程序TLV，重置连接操作除外：传输NAK TLV
ICCP connection torn down NONEXISTENT
ICCP连接已断开不存在
CONNECTING Receive Application Connect TLV OPERATIONAL with A-bit=1
连接接收应用程序连接TLV操作，A位=1
Receive any other Application TLV RESET Action: Transmit NAK TLV
接收任何其他应用程序TLV重置操作：传输NAK TLV
ICCP connection torn down NONEXISTENT
ICCP连接已断开不存在
OPERATIONAL Receive Application Disconnect TLV RESET
操作接收应用程序断开TLV重置
Transmit Application Disconnect TLV RESET
传输应用断开TLV复位
ICCP connection torn down NONEXISTENT
ICCP连接已断开不存在
ICCP Application Connection State Transition Diagram
ICCP应用程序连接状态转换图
+------------+
| |
+---------------->|NONEXISTENT | ICCP connection torn down
| | |<--------------------------+
| +------------+ |
| ICCP connection| ^ ICCP connection |
| established | | torn down |
| | | |
| V | Rx other App TLV/ |
| +-----------+<-----+ Tx NAK TLV |
ICCP | Rx App | | | |
connect| Connect TLV | RESET |------+ |
torn | +-------------| |---------------+ |
down | | +-----------+ Tx App | |
| | ^ ^ ^ ^ Connect TLV| |
| | Tx NAK | | | | | |
| | or | | | | | |
| | Rx non- | | | | | |
| | Connect | | | | | |
| V TLV/Tx NAK | | |Rx NAK TLV V |
| +-----------+ | | | |or +--------+ |
+-| |---+ | | +---------| | |
|CONNREC | | | Rx other |CONNSENT|---------->+
+-| |-+ | | App TLV/ | | |
| +-----------+ | | | Tx NAK +--------+ |
| ^---+ | | |Rx App Connect |
| Rx App | | |TLV (A=1)/ |
| Connect TLV | |Rx App Disconn | Tx App |
| | |or | Connect TLV |
| Tx App Connect | |Tx App Disconn V (A=1) |
| TLV (A=1) | | +------------+ |
| | +------| | |
| Rx other App | |OPERATIONAL |------------>+
| TLV/Tx NAK | | | |
| +------+ +------------+ |
| | ^ Rx App Connect |
| +----------+ | TLV (A=1) |
| | |---------------------+ |
+--->|CONNECTING| |
| |----------------------------------------->+
+----------+
+------------+
| |
+---------------->|NONEXISTENT | ICCP connection torn down
| | |<--------------------------+
| +------------+ |
| ICCP connection| ^ ICCP connection |
| established | | torn down |
| | | |
| V | Rx other App TLV/ |
| +-----------+<-----+ Tx NAK TLV |
ICCP | Rx App | | | |
connect| Connect TLV | RESET |------+ |
torn | +-------------| |---------------+ |
down | | +-----------+ Tx App | |
| | ^ ^ ^ ^ Connect TLV| |
| | Tx NAK | | | | | |
| | or | | | | | |
| | Rx non- | | | | | |
| | Connect | | | | | |
| V TLV/Tx NAK | | |Rx NAK TLV V |
| +-----------+ | | | |or +--------+ |
+-| |---+ | | +---------| | |
|CONNREC | | | Rx other |CONNSENT|---------->+
+-| |-+ | | App TLV/ | | |
| +-----------+ | | | Tx NAK +--------+ |
| ^---+ | | |Rx App Connect |
| Rx App | | |TLV (A=1)/ |
| Connect TLV | |Rx App Disconn | Tx App |
| | |or | Connect TLV |
| Tx App Connect | |Tx App Disconn V (A=1) |
| TLV (A=1) | | +------------+ |
| | +------| | |
| Rx other App | |OPERATIONAL |------------>+
| TLV/Tx NAK | | | |
| +------+ +------------+ |
| | ^ Rx App Connect |
| +----------+ | TLV (A=1) |
| | |---------------------+ |
+--->|CONNECTING| |
| |----------------------------------------->+
+----------+
When an application has information to transfer over ICCP, it triggers the transmission of an "Application Data" message. ICCP guarantees in-order and lossless delivery of data. An application may reject a message or a set of one or more TLVs within a message by using the Notification message with a "NAK TLV". Furthermore, an application may implement its own ACK mechanism, if deemed required, by defining an application-specific TLV to be transported in an "Application Data" message. Note that this document does not define a common ACK mechanism for applications.
当应用程序有信息要通过ICCP传输时，它会触发“应用程序数据”消息的传输。ICCP保证数据的有序和无损传输。应用程序可以通过使用带有“NAK TLV”的通知消息来拒绝消息或消息中一个或多个TLV的集合。此外，如果认为需要，应用程序可以通过定义要在“应用程序数据”消息中传输的特定于应用程序的TLV来实现其自己的ACK机制。请注意，本文档没有为应用程序定义通用的确认机制。
It is left up to the application to define the procedures to handle the situation where a PE receives a "NAK TLV" in response to a transmitted "Application Data" message. Depending on the specifics of the application, it may be favorable to have the PE that sent the NAK explicitly request retransmission of data. On the other hand, for certain applications it may be more suitable to have the original sender of the "Application Data" message handle retransmissions in response to a NAK. ICCP supports both models.
由应用程序定义处理PE接收“NAK TLV”以响应传输的“应用程序数据”消息的情况的程序。根据应用的具体情况，让发送NAK的PE显式地请求数据的重传可能是有利的。另一方面，对于某些应用，可能更适合让“应用数据”消息的原始发送者响应于NAK处理重传。ICCP支持这两种模型。
For certain ICCP applications, it is required that a fairly large amount of RG information be exchanged in a very short period of time. In order to better distribute the load in a multiple-processor system, and to avoid head-of-line blocking to other LDP applications, initiating a separate TCP/IP session between the two LDP speakers may be required.
对于某些ICCP应用，需要在很短的时间内交换相当多的RG信息。为了在多处理器系统中更好地分配负载，并避免对其他LDP应用程序的线路头阻塞，可能需要在两个LDP扬声器之间启动单独的TCP/IP会话。
This procedure is OPTIONAL and does not change the operation of LDP or ICCP.
此程序是可选的，不会改变LDP或ICCP的操作。
A PE that requires a separate LDP session will advertise a separate LDP adjacency with a non-zero label space identifier. This will cause the remote peer to open a separate LDP session for this label space. No labels need to be advertised in this label space, as it is only used for one or a set of ICCP RGs. All relevant LDP and ICCP procedures still apply as described in [RFC5036] and this document.
需要单独LDP会话的PE将使用非零标签空间标识符通告单独的LDP邻接。这将导致远程对等方为此标签空间打开单独的LDP会话。无需在此标签空间中公布标签，因为它仅用于一个或一组ICCP RG。所有相关LDP和ICCP程序仍适用[RFC5036]和本文件所述。
ICCP provides its client applications a notification when a remote PE that is a member of the RG is no longer reachable. In the case of a dedicated interconnect, this indicates that the remote PE node has failed, whereas in the case of a shared interconnect this indicates that the remote PE node has either failed or become isolated from the MPLS network. This information is used by the client applications to
当作为RG成员的远程PE不再可访问时，ICCP向其客户端应用程序提供通知。在专用互连的情况下，这表示远程PE节点发生故障，而在共享互连的情况下，这表示远程PE节点发生故障或与MPLS网络隔离。客户端应用程序使用此信息来
trigger failover according to the procedures of the redundancy protocol employed on the AC and PW. To that end, ICCP does not define its own Keep-Alive mechanism for the purpose of monitoring the health of remote PE nodes but rather reuses existing fault detection mechanisms. The following mechanisms may be used by ICCP to detect PE node failure:
根据AC和PW上采用的冗余协议的程序触发故障切换。为此，ICCP没有定义自己的保持活动机制来监控远程PE节点的健康状况，而是重用现有的故障检测机制。ICCP可使用以下机制检测PE节点故障：
- Bidirectional Forwarding Detection (BFD)
- 双向转发检测（BFD）
Run a BFD session [RFC5880] between the PEs that are members of a given RG, and use that to detect PE node failure. This assumes that resiliency mechanisms are in place to protect connectivity to the remote PE nodes, and hence loss of BFD periodic messages from a given PE node can only mean that the node itself has failed.
在作为给定RG成员的PE之间运行BFD会话[RFC5880]，并使用该会话检测PE节点故障。这假设弹性机制已到位，以保护与远程PE节点的连接，因此，来自给定PE节点的BFD定期消息丢失只能意味着节点本身已发生故障。
- IP Reachability Monitoring
- IP可达性监控
It is possible for a PE to monitor IP-layer connectivity to other members of an RG that are participating in IGP/BGP. When connectivity to a given PE is lost, the local PE interprets that to mean loss of the remote PE node. This technique assumes that resiliency mechanisms are in place to protect the route to the remote PE nodes, and hence loss of IP reachability to a given node can only mean that the node itself has failed.
PE可以监控与参与IGP/BGP的RG其他成员的IP层连接。当与给定PE的连接丢失时，本地PE将其解释为远程PE节点丢失。该技术假设弹性机制已到位，以保护到远程PE节点的路由，因此，失去到给定节点的IP可达性只能意味着节点本身已失败。
It is worth noting here that loss of the LDP session with a PE in an RG is not a reliable indicator that the remote PE itself is down. It is possible, for example, that the remote PE could encounter a local event that would lead to resetting the LDP session, while the PE node would remain operational for traffic forwarding purposes.
这里值得注意的是，与RG中的PE的LDP会话的丢失不是远程PE本身停机的可靠指示。例如，远程PE可能会遇到导致重设LDP会话的本地事件，而PE节点出于业务转发目的将保持操作。
This section defines the messages exchanged at the Application and ICC layers.
本节定义了在应用程序层和ICC层交换的消息。
ICCP requires reliable, in-order, stateful message delivery, as well as capability negotiation between PEs. LDP offers all of these features and is already in wide use in the applications that would also require the ICCP protocol extensions. For these reasons, ICCP takes advantage of the already-defined LDP protocol infrastructure.
ICCP要求可靠、有序、有状态的消息传递，以及PEs之间的能力协商。LDP提供了所有这些特性，并且已经在需要ICCP协议扩展的应用中广泛使用。由于这些原因，ICCP利用了已经定义的LDP协议基础设施。
[RFC5036], Section 3.5 defines a generic LDP message structure. A new set of LDP message types is defined to communicate the ICCP information. LDP message types in the range 0x0700 to 0x070F will be used for ICCP.
[RFC5036]，第3.5节定义了通用LDP消息结构。定义了一组新的LDP消息类型来传递ICCP信息。ICCP将使用0x0700至0x070F范围内的LDP消息类型。
Message types have been allocated by IANA; see Section 12 below for details.
IANA已分配消息类型；详情见下文第12节。
Every ICCP message comprises an ICC-specific LDP Header followed by message data. The format of the ICC Header is as follows:
每个ICCP消息都包含一个ICC特定的LDP报头，后跟消息数据。ICC标题的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- U形位
Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored. Subsequent sections that define messages specify a value for the U-bit.
未知消息位。收到未知消息后，如果U为清除（=0），则向消息发起人返回通知；如果U设置为（=1），未知消息将被静默忽略。定义消息的后续部分指定U位的值。
- Message Type
- 消息类型
Identifies the type of the ICCP message. Must be in the range 0x0700 to 0x070F.
标识ICCP消息的类型。必须在0x0700到0x070F范围内。
- Message Length
- 消息长度
2-octet integer specifying the total length of this message in octets, excluding the "U-bit", "Message Type", and "Length" fields.
2-八位整数，以八位字节为单位指定此消息的总长度，不包括“U位”、“消息类型”和“长度”字段。
- Message ID
- 消息ID
4-octet value used to identify this message. Used by the sending PE to facilitate identifying "RG Notification" messages that may apply to this message. A PE sending an "RG Notification" message in response to this message SHOULD include this Message ID in the "NAK TLV" of the "RG Notification" message; see Section 6.4.
4-用于标识此消息的八位字节值。发送PE用于帮助识别可能适用于此消息的“RG通知”消息。为响应此消息而发送“RG通知”消息的PE应在“RG通知”消息的“NAK TLV”中包含此消息ID；见第6.4节。
- ICC RG ID TLV
- ICC RG ID TLV
A TLV of type 0x0005, length 4, containing a 4-octet unsigned integer designating the Redundancy Group of which the sending device is a member. RG ID value 0x00000000 is reserved by the protocol.
0x0005类型的TLV，长度为4，包含一个4-八位无符号整数，指定发送设备所属的冗余组。RG ID值0x00000000由协议保留。
- Mandatory ICC Parameters
- 强制性ICC参数
Variable-length set of required message parameters. Some messages have no required parameters.
所需消息参数的可变长度集。有些消息没有必需的参数。
For messages that have required parameters, the required parameters MUST appear in the order specified by the individual message specifications in the sections that follow.
对于具有所需参数的消息，所需参数必须按照以下各节中各个消息规范指定的顺序显示。
- Optional ICC Parameters
- 可选ICC参数
Variable-length set of optional message parameters. Many messages have no optional parameters.
可选消息参数的可变长度集。许多消息没有可选参数。
For messages that have optional parameters, the optional parameters may appear in any order.
对于具有可选参数的消息，可选参数可以按任意顺序显示。
The generic format of an ICC parameter is as follows:
ICC参数的通用格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV(s) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV(s) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- U形位
Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification MUST be returned to the message originator and the entire message MUST be ignored; if U is set (=1), the unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. Subsequent sections that define TLVs specify a value for the U-bit.
未知TLV位。收到未知TLV后，如果U为清除（=0），则必须向消息发起人返回通知，并且必须忽略整个消息；如果U设置为（=1），则必须以静默方式忽略未知TLV，并处理消息的其余部分，就像未知TLV不存在一样。定义TLV的后续部分指定U位的值。
- F-bit
- F位
Forward unknown TLV bit. This bit applies only when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the LDP message; if F is set (=1), the unknown TLV is forwarded with the LDP message. Subsequent sections that define TLVs specify a value for the F-bit. By setting both the U- and F-bits, a TLV can be propagated as opaque data through nodes that do not recognize the TLV.
转发未知TLV位。此位仅在设置了U位且包含未知TLV的LDP消息要转发时适用。如果F为clear（=0），则未知TLV不与LDP消息一起转发；如果设置了F（=1），未知TLV将与LDP消息一起转发。定义TLV的后续部分指定F位的值。通过同时设置U位和F位，TLV可以作为不透明数据通过不识别TLV的节点传播。
- Type
- 类型
14 bits indicating the ICC Parameter type.
14位，表示ICC参数类型。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- TLV(s): A set of 0 or more TLVs. Contents will vary according to the message type.
- TLV（s）：一组0个或多个TLV。内容将根据消息类型而有所不同。
The Redundant Object Identifier (ROID) is a generic opaque handle that uniquely identifies a Redundant Object (e.g., link, bundle, VLAN) that is being protected in an RG. It is encoded as follows:
冗余对象标识符（ROID）是一个通用不透明句柄，用于唯一标识RG中受保护的冗余对象（例如链路、捆绑包、VLAN）。其编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the ROID is an 8-octet field encoded as an unsigned integer. The ROID value of 0 is reserved.
其中ROID是编码为无符号整数的8个八位字段。保留ROID值0。
The ROID is carried within application-specific TLVs.
ROID携带在特定于应用的TLV中。
The "RG Connect" message is used to establish the ICCP RG connection in addition to individual Application Connections between PEs in an RG. An "RG Connect" message with no "Application Connect TLV" signals establishment of the ICCP RG connection, whereas an "RG Connect" message with a valid "Application Connect TLV" signals the establishment of an Application Connection in addition to the ICCP RG connection if the latter is not already established.
“RG Connect”消息用于建立ICCP RG连接，以及RG中PE之间的单个应用程序连接。不带“应用程序连接TLV”的“RG Connect”消息表示ICCP RG连接的建立，而带有效“应用程序连接TLV”的“RG Connect”消息表示ICCP RG连接之外的应用程序连接的建立（如果后者尚未建立）。
An implementation MAY send a dedicated "RG Connect" message to set up the ICCP RG connection and a separate "RG Connect" message for each client application. However, all implementations MUST support the receipt of an "RG Connect" message that triggers the setup of the ICCP RG connection as well as a single Application Connection simultaneously.
实现可以发送专用的“RG Connect”消息来设置ICCP RG连接，并为每个客户端应用程序发送单独的“RG Connect”消息。但是，所有实现必须支持接收“RG Connect”消息，该消息同时触发ICCP RG连接和单个应用程序连接的设置。
A PE sends an "RG Connect" message to declare its membership in a Redundancy Group. One such message should be sent to each PE that is a member of the same RG. The set of PEs to which "RG Connect" messages should be transmitted is known via configuration or an auto-discovery mechanism that is outside the scope of this specification. If a device is a member of multiple RGs, it MUST send separate "RG Connect" messages for each RG even if the receiving device(s) happens to be the same.
PE发送“RG Connect”消息以声明其在冗余组中的成员身份。应向属于同一RG成员的每个PE发送一条此类消息。“RG Connect”消息应传输到的一组PEs通过配置或自动发现机制（不在本规范范围内）已知。如果一个设备是多个RG的成员，它必须为每个RG发送单独的“RG Connect”消息，即使接收设备恰好相同。
The format of the "RG Connect" message is as follows:
“RG Connect”消息的格式如下：
i. ICC Header with Message type = "RG Connect Message" (0x0700)
i. 消息类型为“RG连接消息”的ICC标头（0x0700）
ii. ICC Sender Name TLV
二,。ICC发送方名称TLV
iii. Zero or one "Application Connect TLV"
iii.零或一个“应用程序连接TLV”
The currently defined "Application Connect TLVs" are as follows:
当前定义的“应用程序连接TLV”如下所示：
- PW-RED Connect TLV (Section 7.1.1)
- PW-RED连接TLV（第7.1.1节）
- mLACP Connect TLV (Section 7.2.1)
- mLACP连接TLV（第7.2.1节）
The details of these TLVs are discussed in Section 7.
第7节讨论了这些TLV的详细信息。
The "RG Connect" message can contain zero or one "Application Connect TLV".
“RG Connect”消息可以包含零个或一个“Application Connect TLV”。
The "ICC Sender Name TLV" carries the hostname of the sender, encoded in UTF-8 [RFC3629] format. This is used primarily for the purpose of management of the RG and easing network operations. The specific format is shown below:
“ICC发送方名称TLV”包含发送方的主机名，以UTF-8[RFC3629]格式编码。这主要用于管理RG和简化网络操作。具体格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x0001 (from the ICC parameter name space).
设置为0x0001（从ICC参数名称空间）。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Sender Name
- 事件的发送者
An administratively assigned name of the sending device, encoded in UTF-8 format and limited to a maximum of 80 octets. This field does not include a terminating null character.
发送设备的管理分配名称，以UTF-8格式编码，最多不超过80个八位字节。此字段不包括终止的空字符。
The "RG Disconnect" message serves a dual purpose: to signal that a particular Application Connection is being closed within an RG or that the ICCP RG connection itself is being disconnected because the PE wishes to leave the RG. The format of this message is as follows:
“RG Disconnect”（RG断开连接）消息具有双重用途：表示RG内的特定应用程序连接正在关闭，或者ICCP RG连接本身正在断开，因为PE希望离开RG。此消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type = 0x0701 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Code TLV |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Application Disconnect TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameter 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type = 0x0701 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Code TLV |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Application Disconnect TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameter TLVs |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- U形位
U=0
U=0
- Message Type
- 消息类型
The message type for the "RG Disconnect" message is set to 0x0701.
“RG断开”消息的消息类型设置为0x0701。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "Message Type", and "Message Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“消息类型”和“消息长度”字段。
- Message ID
- 消息ID
Defined in Section 6.1.1 above.
定义见上文第6.1.1节。
- ICC RG ID
- ICC RG ID
Defined in Section 6.1.1 above.
定义见上文第6.1.1节。
- Disconnect Code TLV
- 断开代码TLV
The format of this TLV is as follows:
本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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to "Disconnect Code TLV" (0x0004).
设置为“断开连接代码TLV”（0x0004）。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- ICCP Status Code
- ICCP状态代码
A status code that reflects the reason for the disconnect message. Allowed values are "ICCP RG Removed" and "ICCP Application Removed from RG".
反映断开连接消息原因的状态代码。允许的值为“ICCP RG移除”和“ICCP应用程序从RG移除”。
- Optional Application Disconnect TLV
- 可选应用程序断开TLV
Zero or one "Application Disconnect TLV" (defined in Sections 7.1.2 and 7.2.2). If the "RG Disconnect" message has a status code of "RG Removed", then it MUST NOT contain any "Application Disconnect TLVs", as the sending PE is signaling that it has left the RG and thus is disconnecting the ICCP RG connection with all associated client Application Connections. If the message has a status code of "Application Removed from RG", then it MUST contain exactly one "Application Disconnect TLV", as the sending PE is only tearing down the connection for the specified application. Other applications, and the ICCP RG connection, are not to be affected.
零或一个“应用断开TLV”（定义见第7.1.2节和第7.2.2节）。如果“RG Disconnect”消息的状态代码为“RG Removed”，则该消息不得包含任何“Application Disconnect TLV”，因为发送PE发出信号表明其已离开RG，从而断开ICCP RG连接与所有相关客户端应用程序连接的连接。如果消息的状态代码为“Application Removed from RG”，则它必须仅包含一个“Application Disconnect TLV”，因为发送PE仅断开指定应用程序的连接。其他应用程序和ICCP RG连接不受影响。
- Optional Parameter TLVs
- 可选参数TLV
None are defined for this message in this document. This is specified to allow for future extensions.
此文档中未为此邮件定义任何内容。这是为了允许将来扩展而指定的。
A PE sends an "RG Notification" message to indicate one of the following: to reject an ICCP connection, to reject an Application Connection, to reject an entire message, or to reject one or more TLVs within a message. The Notification message MUST only be sent to a PE that is already part of an RG.
PE发送一条“RG通知”消息以指示以下情况之一：拒绝ICCP连接、拒绝应用程序连接、拒绝整个消息或拒绝消息中的一个或多个TLV。通知消息只能发送到已经是RG一部分的PE。
The "RG Notification" message MUST only be used to reject messages or TLVs corresponding to a single ICCP application. In other words, there is a limit of at most a single ICCP application per "RG Notification" message.
“RG通知”消息只能用于拒绝与单个ICCP应用程序对应的消息或TLV。换句话说，每个“RG通知”消息最多只能有一个ICCP应用程序。
The format of the "RG Notification" message is as follows:
“RG通知”信息的格式如下：
i. ICC Header with Message type = "RG Notification Message" (0x0702)
i. 消息类型为“RG通知消息”（0x0702）的ICC标头
ii. Notification Message TLVs
二,。通知消息TLV
The currently defined Notification message TLVs are as follows:
当前定义的通知消息TLV如下所示：
i. ICC Sender Name TLV
i. ICC发送方名称TLV
ii. Negative Acknowledgement (NAK) TLV
二,。否定确认（NAK）TLV
The "ICC Sender Name TLV" uses the same format as the format used in the "RG Connect" message and was described above.
“ICC发送方名称TLV”使用的格式与“RG Connect”消息中使用的格式相同，如上所述。
The "NAK TLV" is defined as follows:
“NAK 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLV(s) |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLV(s) |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to "NAK TLV" (0x0002).
设置为“NAK TLV”（0x0002）。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- ICCP Status Code
- ICCP状态代码
A status code that reflects the reason for the "NAK TLV". Allowed values are as follows:
反映“NAK TLV”原因的状态代码。允许值如下所示：
i. Unknown ICCP RG (0x00010001)
i. 未知ICCP RG（0x0000001）
This code is used to reject a new incoming ICCP connection for an RG that is not configured on the local PE. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message.
此代码用于拒绝未在本地PE上配置的RG的新传入ICCP连接。使用此代码时，“拒绝的消息ID”字段必须包含被拒绝的“RG Connect”消息的消息ID。
ii. ICCP Connection Count Exceeded (0x00010002)
二,。超过ICCP连接计数（0x00010002）
This is used to reject a new incoming ICCP connection that would cause the local PE's ICCP connection count to exceed its capabilities. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message.
这用于拒绝可能导致本地PE的ICCP连接计数超过其能力的新传入ICCP连接。使用此代码时，“拒绝的消息ID”字段必须包含被拒绝的“RG Connect”消息的消息ID。
iii. ICCP Application Connection Count Exceeded (0x00010003)
iii.超过ICCP应用程序连接计数（0x00010003）
This is used to reject a new incoming Application Connection that would cause the local PE's ICCP connection count to exceed its capabilities. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
这用于拒绝可能导致本地PE的ICCP连接计数超过其能力的新传入应用程序连接。使用此代码时，“拒绝的消息ID”字段必须包含拒绝的“RG Connect”消息的消息ID，“可选TLV”中必须包含相应的“应用程序连接TLV”。
iv. ICCP Application not in RG (0x00010004)
iv.不在RG中的ICCP应用程序（0x00010004）
This is used to reject a new incoming Application Connection when the local PE doesn't support the application or the application is not configured in the RG. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
当本地PE不支持应用程序或未在RG中配置应用程序时，这用于拒绝新的传入应用程序连接。使用此代码时，“拒绝的消息ID”字段必须包含拒绝的“RG Connect”消息的消息ID，“可选TLV”中必须包含相应的“应用程序连接TLV”。
v. Incompatible ICCP Protocol Version (0x00010005)
v. 不兼容的ICCP协议版本（0x00010005）
This is used to reject a new incoming Application Connection when the local PE has an incompatible version of the application. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
当本地PE具有不兼容版本的应用程序时，这用于拒绝新的传入应用程序连接。使用此代码时，“拒绝的消息ID”字段必须包含拒绝的“RG Connect”消息的消息ID，“可选TLV”中必须包含相应的“应用程序连接TLV”。
vi. ICCP Rejected Message (0x00010006)
六、ICCP拒绝消息（0x00010006）
This is used to reject an "RG Application Data" message, or one or more TLVs within the message. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Application Data" message.
这用于拒绝“RG应用程序数据”消息或消息中的一个或多个TLV。使用此代码时，“拒绝的消息ID”字段必须包含被拒绝的“RG应用程序数据”消息的消息ID。
vii. ICCP Administratively Disabled (0x00010007)
七,。ICCP管理性禁用（0x00010007）
This is used to reject any ICCP messages from a peer from which the PE is not allowed to exchange ICCP messages due to local administrative policy.
这用于拒绝来自由于本地管理策略而不允许PE交换ICCP消息的对等方的任何ICCP消息。
- Rejected Message ID
- 拒绝的消息ID
If non-zero, a 4-octet value that identifies the peer message to which the "NAK TLV" refers. If zero, no specific peer message is being identified.
如果非零，则为4个八位字节的值，用于标识“NAK TLV”所指的对等消息。如果为零，则未识别特定的对等消息。
- Optional TLV(s)
- 可选TLV
A set of one or more optional TLVs. If the status code is "Rejected Message", then this field contains the TLV or TLVs that were rejected. If the entire message is rejected, all of its TLVs MUST be present in this field; otherwise, the subset of TLVs that were rejected MUST be echoed in this field.
一组一个或多个可选TLV。如果状态代码为“已拒绝消息”，则此字段包含已拒绝的TLV或TLV。如果整个消息被拒绝，则其所有TLV必须出现在该字段中；否则，被拒绝的TLV子集必须在该字段中回显。
If the status code is "Incompatible Protocol Version", then this field contains the original "Application Connect TLV" sent by the peer, in addition to the "Requested Protocol Version TLV" defined below:
如果状态代码为“不兼容协议版本”，则此字段包含对等方发送的原始“应用程序连接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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Reference | Requested Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Reference | Requested Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0003 for "Requested Protocol Version TLV".
“请求的协议版本TLV”设置为0x0003。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Connection Reference
- 连接引用
Set to the "Type" field of the "Application Connect TLV" that was rejected because of incompatible version.
设置为“应用程序连接TLV”的“类型”字段，该字段因版本不兼容而被拒绝。
- Requested Version
- 要求的版本
The version of the application supported by the transmitting device. For this version of the protocol, it is set to 0x0001.
传输设备支持的应用程序版本。对于此版本的协议，它设置为0x0001。
The "RG Application Data" message is used to transport application data between PEs within an RG. A single message can be used to carry data from only one application. Multiple Application TLVs are allowed in a single message, as long as all of these TLVs belong to the same application. The format of the "Application Data" message is as follows:
“RG应用程序数据”消息用于在RG内的PE之间传输应用程序数据。一条消息只能用于承载来自一个应用程序的数据。一条消息中允许多个应用程序TLV，只要所有这些TLV都属于同一个应用程序。“应用程序数据”信息的格式如下：
i. ICC Header with Message type = "RG Application Data Message" (0x0703)
i. 消息类型为“RG应用程序数据消息”（0x0703）的ICC标头
ii. Application-specific TLVs
二,。特定于应用程序的TLV
The details of these TLVs are discussed in Section 7. All application-specific TLVs in one "RG Application Data" message MUST belong to a single application but MAY reference different ROs.
第7节讨论了这些TLV的详细信息。一条“RG应用程序数据”消息中的所有特定于应用程序的TLV必须属于单个应用程序，但可能引用不同的ROs。
This section discusses the "ICCP TLVs" for the Pseudowire Redundancy application.
本节讨论伪线冗余应用的“ICCP TLV”。
This TLV is included in the "RG Connect" message to signal the establishment of a PW-RED Application Connection.
该TLV包含在“RG Connect”消息中，以指示建立PW-RED应用程序连接。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0010 for "PW-RED Connect TLV".
“PW-RED Connect TLV”设置为0x0010。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Protocol Version
- 协议版本
The version of this particular protocol for the purposes of ICCP. This is set to 0x0001.
为ICCP的目的，本特定协议的版本。这设置为0x0001。
- A-bit
- 一点儿
Acknowledgement bit. Set to 1 if the sender has received a "PW-RED Connect TLV" from the recipient. Otherwise, set to 0.
确认位。如果发送方从接收方收到“PW-RED Connect TLV”，则设置为1。否则，设置为0。
- Reserved
- 含蓄的
Reserved for future use.
保留供将来使用。
- Optional Sub-TLVs
- 可选子TLV
There are no optional sub-TLVs defined for this version of the protocol. This document does not impose any restrictions on the length of the sub-TLVs.
没有为此版本的协议定义可选的子TLV。本文件不对子TLV的长度施加任何限制。
This TLV is used in an "RG Disconnect" message to indicate that the connection for the PW-RED application is to be terminated.
该TLV用于“RG断开”消息，以指示PW-RED应用程序的连接将被终止。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0011 for "PW-RED Disconnect TLV".
“PW-RED断开TLV”设置为0x0011。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Optional Sub-TLVs
- 可选子TLV
The only optional sub-TLV defined for this version of the protocol is the "PW-RED Disconnect Cause TLV" defined in Section 7.1.2.1.
本版本协议中定义的唯一可选子TLV是第7.1.2.1节中定义的“PW-RED断开原因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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0019 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0019 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0019 for "PW-RED Disconnect Cause TLV".
将“PW-RED断开原因TLV”设置为0x0019。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Disconnect Cause String
- 断开原因字符串
Variable-length string specifying the reason for the disconnect, encoded in UTF-8 format. The string does not include a terminating null character. Used for network management.
指定断开原因的可变长度字符串，以UTF-8格式编码。该字符串不包含终止的空字符。用于网络管理。
The "PW-RED Config TLV" is used in the "RG Application Data" message and has the following format:
“RG应用程序数据”消息中使用了“PW-RED配置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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Priority | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID TLV or Generalized PW ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Priority | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID TLV or Generalized PW ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0012 for "PW-RED Config TLV".
“PW-RED配置TLV”设置为0x0012。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- ROID
- ROID
As defined in Section 6.1.3.
如第6.1.3节所定义。
- PW Priority
- 优先权
2 octets. Pseudowire Priority. Used to indicate which PW has better priority to go into active state. Numerically lower numbers are better priority. In case of a tie, the PE with the numerically lower identifier (i.e., IP Address) has better priority.
2个八位组。伪线优先级。用于指示哪个PW具有进入激活状态的更好优先级。数字越小，优先级越高。在平局的情况下，具有数字更低标识符（即IP地址）的PE具有更好的优先级。
- Flags
- 旗帜
Valid values are as follows:
有效值如下所示：
i. Synchronized (0x01)
i. 已同步（0x01）
Indicates that the sender has concluded transmitting all pseudowire configuration for a given service.
指示发送方已完成发送给定服务的所有伪线配置。
ii. Purge Configuration (0x02)
二,。清除配置（0x02）
Indicates that the pseudowire is no longer configured for PW-RED operation.
表示不再为PW-RED操作配置伪导线。
iii. Independent Mode (0x04)
三、独立模式（0x04）
Indicates that the pseudowire is configured for redundancy using the Independent Mode of operation, per Section 5.1 of [RFC6870].
表示根据[RFC6870]第5.1节，使用独立操作模式将伪线配置为冗余。
iv. Independent Mode with Request Switchover (0x08)
iv.带请求切换的独立模式（0x08）
Indicates that the pseudowire is configured for redundancy using the Independent Mode of operation with the use of the "Request Switchover" bit, per Section 6.3 of [RFC6870].
表示根据[RFC6870]第6.3节，通过使用“请求切换”位，使用独立操作模式将伪线配置为冗余。
v. Master Mode (0x10)
v. 主模式（0x10）
Indicates that the pseudowire is configured for redundancy using the Master/Slave Mode of operation, with the advertising PE acting as Master, per Section 5.2 of [RFC6870].
表示根据[RFC6870]第5.2节，使用主/从操作模式将伪线配置为冗余，广告PE作为主。
vi. Slave Mode (0x20)
vi.从模式（0x20）
Indicates that the pseudowire is configured for redundancy using the Master/Slave Mode of operation, with the advertising PE acting as Slave, per Section 5.2 of [RFC6870].
表示根据[RFC6870]第5.2节，使用主/从操作模式将伪线配置为冗余，广告PE作为从机。
- Sub-TLVs
- 子TLV
The "PW-RED Config TLV" includes the following two sub-TLVs:
“PW-RED配置TLV”包括以下两个子TLV：
i. Service Name TLV
i. 服务名称TLV
ii. One of the following: PW ID TLV or Generalized PW ID TLV
二,。以下选项之一：PW ID TLV或广义PW ID TLV
The format of the sub-TLVs is defined in Sections 7.1.3.1 through 7.1.3.3.
第7.1.3.1至7.1.3.3节定义了子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0013 for "Service Name TLV".
“服务名称TLV”设置为0x0013。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Service Name
- 服务名称
The name of the L2VPN service instance, encoded in UTF-8 format and up to 80 octets in length. The string does not include a terminating null character.
L2VPN服务实例的名称，以UTF-8格式编码，长度最多为80个八位字节。该字符串不包含终止的空字符。
This TLV is used to communicate the configuration of PWs for VPWS.
该TLV用于传达VPWS的PWs配置。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0014 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0014 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0014 for "PW ID TLV".
“PW ID TLV”设置为0x0014。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Peer ID
- 对等ID
4-octet LDP Router ID of the peer at the far end of the PW.
PW远端对等方的4个八位LDP路由器ID。
- Group ID
- 组ID
Same as Group ID in [RFC4447], Section 5.2.
与[RFC4447]第5.2节中的组ID相同。
- PW ID
- PW ID
Same as PW ID in [RFC4447], Section 5.2.
与[RFC4447]第5.2节中的PW ID相同。
This TLV is used to communicate the configuration of PWs for VPLS.
该TLV用于传达VPL的PWs配置。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0015 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0015 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0015 for "Generalized PW ID TLV".
“通用PW ID TLV”设置为0x0015。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- AGI, AII, SAII, and TAII
- AGI，所有，Sai，和Tai
Defined in [RFC4447], Section 5.3.2.
定义见[RFC4447]第5.3.2节。
The "PW-RED State TLV" is used in the "RG Application Data" message. This TLV is used by a device to report its PW status to other members in the RG.
“RG应用数据”消息中使用了“PW-RED状态TLV”。该TLV由设备用于向RG中的其他成员报告其PW状态。
The format of this TLV is as follows:
本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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0016 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0016 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0016 for "PW-RED State TLV".
“PW-RED状态TLV”设置为0x0016。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- ROID
- ROID
As defined in Section 6.1.3.
如第6.1.3节所定义。
- Local PW State
- 局部PW状态
The status of the PW as determined by the sending PE, encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
由发送PE确定的PW状态，编码格式与[RFC4447]中定义并在[RFC6870]中扩展的“PW状态TLV”的“状态代码”字段相同。
- Remote PW State
- 远程PW状态
The status of the PW as determined by the remote peer of the sending PE. Encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
由发送PE的远程对等方确定的PW状态。编码格式与[RFC4447]中定义并在[RFC6870]中扩展的“PW状态TLV”的“状态代码”字段相同。
The "PW-RED Synchronization Request TLV" is used in the "RG Application Data" message. This TLV is used by a device to request that its peer retransmit configuration or operational state. The following information can be requested:
“RG应用程序数据”消息中使用了“PW-RED同步请求TLV”。设备使用此TLV请求其对等方重新传输配置或操作状态。可要求提供以下信息：
- configuration and/or state for one or more pseudowires
- 一条或多条伪导线的配置和/或状态
- configuration and/or state for all pseudowires
- 所有伪导线的配置和/或状态
- configuration and/or state for all pseudowires in a given service
- 给定服务中所有伪线的配置和/或状态
The format of the TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0017 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0017 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0017 for "PW-RED Synchronization Request TLV".
“PW-RED同步请求TLV”设置为0x0017。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Request Number
- 请求号码
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a response. The value of 0 is reserved for unsolicited synchronization and MUST NOT be used in the "PW-RED Synchronization Request TLV". Given the use of TCP, there are no issues associated with the wrap-around of the Request Number.
2个八位组。唯一标识请求的无符号整数。用于将请求与响应匹配。0的值保留用于未经请求的同步，并且不得在“PW-RED同步请求TLV”中使用。考虑到TCP的使用，不存在与请求号环绕相关的问题。
- C-bit
- C位
Set to 1 if the request is for configuration data. Otherwise, set to 0.
如果请求是配置数据，则设置为1。否则，设置为0。
- S-bit
- S位
Set to 1 if the request is for running state data. Otherwise, set to 0.
如果请求用于运行状态数据，则设置为1。否则，设置为0。
- Request Type
- 请求类型
14 bits specifying the request type, encoded as follows:
14位，指定请求类型，编码如下：
0x00 Request Data for specified pseudowire(s) 0x01 Request Data for all pseudowires in specified service(s) 0x3FFF Request All Data
0x00指定伪线的请求数据0x01指定服务中所有伪线的请求数据0x3FFF请求所有数据
- Optional Sub-TLVs
- 可选子TLV
A set of zero or more TLVs, as follows:
一组零个或多个TLV，如下所示：
If the "Request Type" field is set to 0x00, then this field contains one or more "PW ID TLVs" or "Generalized PW ID TLVs". If the "Request Type" field is set to 0x01, then this field contains one or more "Service Name TLVs". If the "Request Type" field is set to 0x3FFF, then this field MUST be empty. This document does not impose any restrictions on the length of the sub-TLVs.
如果“请求类型”字段设置为0x00，则此字段包含一个或多个“PW ID TLV”或“广义PW ID TLV”。如果“请求类型”字段设置为0x01，则此字段包含一个或多个“服务名称TLV”。如果“请求类型”字段设置为0x3FFF，则此字段必须为空。本文件不对子TLV的长度施加任何限制。
The "PW-RED Synchronization Data TLV" is used in the "RG Application Data" message. A pair of these TLVs is used by a device to delimit a set of TLVs that are sent in response to a "PW-RED Synchronization Request TLV". The delimiting TLVs signal the start and end of the synchronization data and associate the response with its corresponding request via the "Request Number" field.
“RG应用程序数据”消息中使用了“PW-RED同步数据TLV”。设备使用这些TLV中的一对来限定响应“PW-RED同步请求TLV”而发送的一组TLV。定界TLV向同步数据的开始和结束发送信号，并通过“请求编号”字段将响应与其相应的请求相关联。
The "PW-RED Synchronization Data TLVs" are also used for unsolicited advertisements of complete PW-RED configuration and operational state data. In this case, the "Request Number" field MUST be set to 0.
“PW-RED同步数据TLV”还用于完整PW-RED配置和运行状态数据的非请求发布。在这种情况下，“请求编号”字段必须设置为0。
This TLV has the following format:
此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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0018 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0018 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0018 for "PW-RED Synchronization Data TLV".
“PW-RED同步数据TLV”设置为0x0018。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Request Number
- 请求号码
2 octets. Unsigned integer identifying the Request Number from the "PW-RED Synchronization Request TLV" that solicited this synchronization data response.
2个八位组。标识请求此同步数据响应的“PW-RED同步请求TLV”中的请求号的无符号整数。
- Flags
- 旗帜
2 octets. Response flags encoded as follows:
2个八位组。响应标志编码如下：
0x00 Synchronization Data Start 0x01 Synchronization Data End
0x00同步数据开始0x01同步数据结束
This section discusses the "ICCP TLVs" for Ethernet attachment circuit redundancy using the multi-chassis LACP (mLACP) application.
本节讨论使用多机箱LACP（mLACP）应用程序实现以太网连接电路冗余的“ICCP TLV”。
This TLV is included in the "RG Connect" message to signal the establishment of an mLACP Application Connection.
此TLV包含在“RG Connect”消息中，以指示建立mLACP应用程序连接。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0030 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0030 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0030 for "mLACP Connect TLV".
“mLACP连接TLV”设置为0x0030。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Protocol Version
- 协议版本
The version of this particular protocol for the purposes of ICCP. This is set to 0x0001.
为ICCP的目的，本特定协议的版本。这设置为0x0001。
- A-bit
- 一点儿
Acknowledgement bit. Set to 1 if the sender has received an "mLACP Connect TLV" from the recipient. Otherwise, set to 0.
确认位。如果发送方从接收方收到“mLACP Connect TLV”，则设置为1。否则，设置为0。
- Reserved
- 含蓄的
Reserved for future use.
保留供将来使用。
- Optional Sub-TLVs
- 可选子TLV
There are no optional sub-TLVs defined for this version of the protocol.
没有为此版本的协议定义可选的子TLV。
This TLV is used in an "RG Disconnect" message to indicate that the connection for the mLACP application is to be terminated.
此TLV用于“RG断开”消息中，以指示mLACP应用程序的连接将被终止。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0031 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0031 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0031 for "mLACP Disconnect TLV".
“mLACP断开TLV”设置为0x0031。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Optional Sub-TLVs
- 可选子TLV
The only optional sub-TLV defined for this version of the protocol is the "mLACP Disconnect Cause TLV" defined in Section 7.2.2.1.
本版本协议定义的唯一可选子TLV是第7.2.2.1节中定义的“mLACP断开原因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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x003A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x003A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x003A for "mLACP Disconnect Cause TLV".
将“mLACP断开原因TLV”设置为0x003A。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Disconnect Cause String
- 断开原因字符串
Variable-length string specifying the reason for the disconnect. Used for network management.
指定断开原因的可变长度字符串。用于网络管理。
The "mLACP System Config TLV" is sent in the "RG Application Data" message. This TLV announces the local node's LACP system parameters to the RG peers.
“mLACP系统配置TLV”在“RG应用程序数据”消息中发送。该TLV向RG对等方宣布本地节点的LACP系统参数。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0032 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0032 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0032 for "mLACP System Config TLV".
“mLACP系统配置TLV”设置为0x0032。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- System ID
- 系统ID
6-octet field encoding the System ID used by LACP, as specified in [IEEE-802.1AX], Section 5.3.2.
按照[IEEE-802.1AX]第5.3.2节的规定，编码LACP使用的系统ID的6个八位组字段。
- System Priority
- 系统优先级
2 octets encoding the LACP System Priority, as defined in [IEEE-802.1AX], Section 5.3.2.
2个编码LACP系统优先级的八位字节，如[IEEE-802.1AX]第5.3.2节所定义。
- Node ID
- 节点ID
1 octet. LACP Node ID. Used to ensure that the LACP Port Numbers are unique across all devices in an RG. Valid values are in the range 0-7. Uniqueness of the LACP Port Numbers across RG members is ensured by encoding the Port Numbers as follows:
1个八位组。LACP节点ID。用于确保LACP端口号在RG中的所有设备上都是唯一的。有效值的范围为0-7。通过对端口号进行如下编码，确保RG成员间LACP端口号的唯一性：
- Most significant bit always set to 1
- 最高有效位始终设置为1
- The next 3 most significant bits set to Node ID
- 设置为节点ID的下3个最高有效位
- Remaining 12 bits freely assigned by the system
- 剩余12位由系统自由分配
The "mLACP Aggregator Config TLV" is sent in the "RG Application Data" message. This TLV is used to notify RG peers about the local configuration state of an Aggregator.
“mLACP聚合器配置TLV”在“RG应用程序数据”消息中发送。此TLV用于通知RG对等方聚合器的本地配置状态。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0036 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Member Ports Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Agg Name Len | Aggregator Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0036 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Member Ports Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Agg Name Len | Aggregator Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0036 for "mLACP Aggregator Config TLV".
“mLACP聚合器配置TLV”设置为0x0036。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- ROID
- ROID
Defined in Section 6.1.3 above.
定义见上文第6.1.3节。
- Aggregator ID
- 聚合器ID
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
2个八位组。[IEEE-802.1AX]第5.4.6节规定的LACP聚合器标识符。
- MAC Address
- MAC地址
6 octets encoding the Aggregator Media Access Control (MAC) address.
编码聚合器媒体访问控制（MAC）地址的6个八位字节。
- Actor Key
- 演员键
2 octets. LACP Actor Key for the corresponding Aggregator, as specified in [IEEE-802.1AX], Section 5.3.5.
2个八位组。[IEEE-802.1AX]第5.3.5节规定的相应聚合器的LACP参与者密钥。
- Member Ports Priority
- 成员端口优先级
2 octets. LACP administrative port priority associated with all interfaces bound to the Aggregator. This field is valid only when the "Flags" field has "Priority Set" asserted.
2个八位组。与绑定到聚合器的所有接口关联的LACP管理端口优先级。仅当“标志”字段已断言“优先级设置”时，此字段才有效。
- Flags
- 旗帜
Valid values are as follows:
有效值如下所示：
i. Synchronized (0x01)
i. 已同步（0x01）
Indicates that the sender has concluded transmitting all Aggregator configuration information.
指示发送方已完成所有聚合器配置信息的传输。
ii. Purge Configuration (0x02)
二,。清除配置（0x02）
Indicates that the Aggregator is no longer configured for mLACP operation.
表示不再为mLACP操作配置聚合器。
iii. Priority Set (0x04)
三、优先级设置（0x04）
Indicates that the "Member Ports Priority" field is valid.
指示“成员端口优先级”字段有效。
- Agg Name Len
- Agg Name Len
1 octet. Length of the "Aggregator Name" field in octets.
1个八位组。“聚合器名称”字段的长度（以八位字节为单位）。
- Aggregator Name
- 聚合器名称
Aggregator name, encoded in UTF-8 format, up to a maximum of 20 octets. Used for ease of management. The string does not include a terminating null character.
聚合器名称，以UTF-8格式编码，最多20个八位字节。用于便于管理。该字符串不包含终止的空字符。
The "mLACP Port Config TLV" is sent in the "RG Application Data" message. This TLV is used to notify RG peers about the local configuration state of a port.
“mLACP端口配置TLV”在“RG应用程序数据”消息中发送。此TLV用于通知RG对等方端口的本地配置状态。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0033 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | MAC Address |
+-------------------------------+ +
| |
+---------------------------------------------------------------+
| Actor Key | Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Port Name Len | Port Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0033 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | MAC Address |
+-------------------------------+ +
| |
+---------------------------------------------------------------+
| Actor Key | Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Port Name Len | Port Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0033 for "mLACP Port Config TLV".
“mLACP端口配置TLV”设置为0x0033。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Port Number
- 端口号
2 octets. LACP Port Number for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above.
2个八位组。[IEEE-802.1AX]第5.3.4节中规定的相应接口的LACP端口号。端口号必须用节点ID编码，如上所述。
- MAC Address
- MAC地址
6 octets encoding the port MAC address.
6个八位字节编码端口MAC地址。
- Actor Key
- 演员键
2 octets. LACP Actor Key for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.5.
2个八位组。[IEEE-802.1AX]第5.3.5节规定的相应接口的LACP参与者密钥。
- Port Priority
- 端口优先级
2 octets. LACP administrative port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. This field is valid only when the "Flags" field has "Priority Set" asserted.
2个八位组。[IEEE-802.1AX]第5.3.4节规定的相应接口的LACP管理端口优先级。仅当“标志”字段已断言“优先级设置”时，此字段才有效。
- Port Speed
- 端口速度
4-octet integer encoding the port's current bandwidth in units of 1,000,000 bits per second. This field corresponds to the ifHighSpeed object of the IF-MIB [RFC2863].
4-octet整数，以每秒1000000位为单位对端口的当前带宽进行编码。该字段对应于IF-MIB[RFC2863]的ifHighSpeed对象。
- Flags
- 旗帜
Valid values are as follows:
有效值如下所示：
i. Synchronized (0x01)
i. 已同步（0x01）
Indicates that the sender has concluded transmitting all member link port configurations for a given Aggregator.
指示发送方已完成发送给定聚合器的所有成员链接端口配置。
ii. Purge Configuration (0x02)
二,。清除配置（0x02）
Indicates that the port is no longer configured for mLACP operation.
表示不再为mLACP操作配置端口。
iii. Priority Set (0x04)
三、优先级设置（0x04）
Indicates that the "Port Priority" field is valid.
指示“端口优先级”字段有效。
- Port Name Len
- 端口名Len
1 octet. Length of the "Port Name" field in octets.
1个八位组。“端口名”字段的长度（以八位字节为单位）。
- Port Name
- 端口名
Corresponds to the ifName object of the IF-MIB [RFC2863]. Encoded in UTF-8 format and truncated to 20 octets. Port Name does not include a terminating null character.
对应于IF-MIB[RFC2863]的ifName对象。以UTF-8格式编码并截断为20个八位字节。端口名不包括终止的空字符。
The "mLACP Port Priority TLV" is sent in the "RG Application Data" message. This TLV is used by a device to either advertise its operational Port Priority to other members in the RG or authoritatively request that a particular member of an RG change its port priority.
“mLACP端口优先级TLV”在“RG应用程序数据”消息中发送。设备使用此TLV向RG中的其他成员公布其操作端口优先级，或授权请求RG的特定成员更改其端口优先级。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0034 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | Last Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0034 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | Last Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0034 for "mLACP Port Priority TLV".
“mLACP端口优先级TLV”设置为0x0034。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- OpCode
- 操作码
2 octets identifying the operational code point for the TLV, encoded as follows:
2个八位字节，标识TLV的操作代码点，编码如下：
0x00 Local Priority Change Notification 0x01 Remote Request for Priority Change
0x00本地优先级更改通知0x01远程优先级更改请求
- Port Number
- 端口号
2-octet field representing the LACP Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. When the value of this field is 0, it denotes all ports bound to the Aggregator specified in the "Aggregator ID" field. When non-zero, the Port Number MUST be encoded with the Node ID, as discussed above.
2-表示LACP端口号的八位字节字段，如[IEEE-802.1AX]第5.3.4节所述。当此字段的值为0时，它表示绑定到“聚合器ID”字段中指定的聚合器的所有端口。当非零时，端口号必须用节点ID编码，如上所述。
- Aggregator ID
- 聚合器ID
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
2个八位组。[IEEE-802.1AX]第5.4.6节规定的LACP聚合器标识符。
- Last Port Priority
- 最后端口优先级
2 octets. LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the previous operational value of port priority. For remote ports, this field encodes the operational port priority last known to the PE via notifications received from its peers in the RG.
2个八位组。根据[IEEE-802.1AX]第5.3.4节的规定，相应接口的LACP端口优先级。对于本地端口，此字段对端口优先级的先前操作值进行编码。对于远程端口，此字段通过从RG中的对等方接收的通知对PE最后知道的操作端口优先级进行编码。
- Current Port Priority
- 当前端口优先级
2 octets. LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the new operational value of port priority being advertised by the PE. For remote ports, this field specifies the new port priority being requested by the PE.
2个八位组。根据[IEEE-802.1AX]第5.3.4节的规定，相应接口的LACP端口优先级。对于本地端口，此字段对PE播发的端口优先级的新操作值进行编码。对于远程端口，此字段指定PE请求的新端口优先级。
The "mLACP Port State TLV" is used in the "RG Application Data" message. This TLV is used by a device to report its LACP port status to other members in the RG.
“RG应用程序数据”消息中使用“mLACP端口状态TLV”。设备使用此TLV向RG中的其他成员报告其LACP端口状态。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0035 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Port Number | Partner Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Partner State | Actor State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Port Number | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Selected | Port State | Aggregator 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0035 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Port Number | Partner Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Partner State | Actor State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Port Number | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Selected | Port State | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0035 for "mLACP Port State TLV".
“mLACP端口状态TLV”设置为0x0035。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Partner System ID
- 合作伙伴系统ID
6 octets. The LACP Partner System ID for the corresponding interface, encoded as a MAC address as specified in [IEEE-802.1AX], Section 5.4.2.2, item r.
6个八位组。对应接口的LACP伙伴系统ID，编码为[IEEE-802.1AX]第5.4.2.2节第r项中规定的MAC地址。
- Partner System Priority
- 合作伙伴系统优先级
2-octet field specifying the LACP Partner System Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item q.
按照[IEEE-802.1AX]第5.4.2.2节第q项的规定，指定LACP合作伙伴系统优先级的2个八位组字段。
- Partner Port Number
- 合作伙伴端口号
2 octets encoding the LACP Partner Port Number, as specified in [IEEE-802.1AX], Section 5.4.2.2, item u. The Port Number MUST be encoded with the Node ID, as discussed above.
按照[IEEE-802.1AX]第5.4.2.2节第u项的规定，编码LACP合作伙伴端口号的2个八位字节。端口号必须用节点ID编码，如上所述。
- Partner Port Priority
- 伙伴端口优先级
2-octet field encoding the LACP Partner Port Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item t.
按照[IEEE-802.1AX]第5.4.2.2节第t项的规定，编码LACP伙伴端口优先级的2个八位组字段。
- Partner Key
- 合作伙伴密钥
2-octet field representing the LACP Partner Key, as defined in [IEEE-802.1AX], Section 5.4.2.2, item s.
2-表示LACP合作伙伴密钥的八位字节字段，如[IEEE-802.1AX]第5.4.2.2节第s项所定义。
- Partner State
- 伙伴国
1-octet field encoding the LACP Partner State Variable, as defined in [IEEE-802.1AX], Section 5.4.2.2, item v.
1-编码LACP伙伴状态变量的八位字节字段，如[IEEE-802.1AX]第5.4.2.2节第v项所定义。
- Actor State
- 行为体状态
1 octet encoding the LACP Actor State Variable for the port, as specified in [IEEE-802.1AX], Section 5.4.2.2, item m.
按照[IEEE-802.1AX]第5.4.2.2节第m项的规定，1个八位组编码端口的LACP参与者状态变量。
- Actor Port Number
- 参与者端口号
2-octet field representing the LACP Actor Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above.
如[IEEE-802.1AX]第5.3.4节所述，表示LACP参与者端口号的2个八位字节字段。端口号必须用节点ID编码，如上所述。
- Actor Key
- 演员键
2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5.
按照[IEEE-802.1AX]第5.3.5节的规定，编码LACP参与者操作密钥的2个八位组字段。
- Selected
- 挑选出来的
1 octet encoding the LACP "Selected" variable, defined in [IEEE-802.1AX], Section 5.4.8 as follows:
1个八位组，对[IEEE-802.1AX]第5.4.8节中定义的LACP“选定”变量进行编码，如下所示：
0x00 SELECTED 0x01 UNSELECTED 0x02 STANDBY
0x00已选择0x01未选择0x02待机
- Port State
- 港口国
1 octet encoding the operational state of the port as follows:
1个八位字节，对端口的操作状态进行编码，如下所示：
0x00 Up 0x01 Down 0x02 Administratively Down 0x03 Test (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)
0x00向上0x01向下0x02管理性向下0x03测试（例如，IEEE 802.3ah OAM侵入性环回模式）
- Aggregator ID
- 聚合器ID
2 octets. LACP Aggregator Identifier to which this port is bound based on the outcome of the LACP selection logic.
2个八位组。根据LACP选择逻辑的结果将此端口绑定到的LACP聚合器标识符。
The "mLACP Aggregator State TLV" is used in the "RG Application Data" message. This TLV is used by a device to report its Aggregator status to other members in the RG.
“RG应用程序数据”消息中使用“mLACP聚合器状态TLV”。设备使用此TLV向RG中的其他成员报告其聚合器状态。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0037 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Agg State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0037 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Agg State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0037 for "mLACP Aggregator State TLV".
“mLACP聚合器状态TLV”设置为0x0037。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Partner System ID
- 合作伙伴系统ID
6 octets. The LACP Partner System ID for the corresponding interface, encoded as a MAC address as specified in [IEEE-802.1AX], Section 5.4.2.2, item r.
6个八位组。对应接口的LACP伙伴系统ID，编码为[IEEE-802.1AX]第5.4.2.2节第r项中规定的MAC地址。
- Partner System Priority
- 合作伙伴系统优先级
2-octet field specifying the LACP Partner System Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item q.
按照[IEEE-802.1AX]第5.4.2.2节第q项的规定，指定LACP合作伙伴系统优先级的2个八位组字段。
- Partner Key
- 合作伙伴密钥
2-octet field representing the LACP Partner Key, as defined in [IEEE-802.1AX], Section 5.4.2.2, item s.
2-表示LACP合作伙伴密钥的八位字节字段，如[IEEE-802.1AX]第5.4.2.2节第s项所定义。
- Aggregator ID
- 聚合器ID
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
2个八位组。[IEEE-802.1AX]第5.4.6节规定的LACP聚合器标识符。
- Actor Key
- 演员键
2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5.
按照[IEEE-802.1AX]第5.3.5节的规定，编码LACP参与者操作密钥的2个八位组字段。
- Agg State
- Agg状态
1 octet encoding the operational state of the Aggregator as follows:
1个八位字节，对聚合器的操作状态进行编码，如下所示：
0x00 Up 0x01 Down 0x02 Administratively Down 0x03 Test (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)
0x00向上0x01向下0x02管理性向下0x03测试（例如，IEEE 802.3ah OAM侵入性环回模式）
The "mLACP Synchronization Request TLV" is used in the "RG Application Data" message. This TLV is used by a device to request that its peer retransmit configuration or operational state. The following information can be requested:
“RG应用程序数据”消息中使用“mLACP同步请求TLV”。设备使用此TLV请求其对等方重新传输配置或操作状态。可要求提供以下信息：
- system configuration and/or state
- 系统配置和/或状态
- configuration and/or state for a specific port
- 特定端口的配置和/或状态
- configuration and/or state for all ports with a specific LACP Key
- 具有特定LACP密钥的所有端口的配置和/或状态
- configuration and/or state for all mLACP ports
- 所有mLACP端口的配置和/或状态
- configuration and/or state for a specific Aggregator
- 特定聚合器的配置和/或状态
- configuration and/or state for all Aggregators with a specific LACP Key
- 具有特定LACP密钥的所有聚合器的配置和/或状态
- configuration and/or state for all mLACP Aggregators
- 所有mLACP聚合器的配置和/或状态
The format of the TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0038 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number / Aggregator ID | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0038 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number / Aggregator ID | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0038 for "mLACP Synchronization Request TLV".
“mLACP同步请求TLV”设置为0x0038。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Request Number
- 请求号码
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a response. The value of 0 is reserved for unsolicited synchronization and MUST NOT be used in the "mLACP Synchronization Request TLV".
2个八位组。唯一标识请求的无符号整数。用于将请求与响应匹配。0的值保留用于未经请求的同步，并且不得在“mLACP同步请求TLV”中使用。
- C-bit
- C位
Set to 1 if the request is for configuration data. Otherwise, set to 0.
如果请求是配置数据，则设置为1。否则，设置为0。
- S-bit
- S位
Set to 1 if the request is for running state data. Otherwise, set to 0.
如果请求用于运行状态数据，则设置为1。否则，设置为0。
- Request Type
- 请求类型
14 bits specifying the request type, encoded as follows:
14位，指定请求类型，编码如下：
0x00 Request System Data 0x01 Request Aggregator Data 0x02 Request Port Data 0x3FFF Request All Data
0x00请求系统数据0x01请求聚合器数据0x02请求端口数据0x3FFF请求所有数据
- Port Number / Aggregator ID
- 端口号/聚合器ID
2 octets. When the "Request Type" field is set to "Request Port Data", this field encodes the LACP Port Number for the requested port. When the "Request Type" field is set to "Request Aggregator Data", this field encodes the Aggregator ID of the requested Aggregator. When the value of this field is 0, it denotes that information for all ports (or Aggregators) whose LACP Key is specified in the "Actor Key" field is being requested.
2个八位组。当“请求类型”字段设置为“请求端口数据”时，该字段对请求端口的LACP端口号进行编码。当“请求类型”字段设置为“请求聚合器数据”时，此字段对请求聚合器的聚合器ID进行编码。当此字段的值为0时，表示正在请求其LACP密钥在“Actor Key”字段中指定的所有端口（或聚合器）的信息。
- Actor Key
- 演员键
2 octets. LACP Actor Key for the corresponding port or Aggregator. When the value of this field is 0 (and the Port Number / Aggregator ID field is 0 as well), it denotes that information for all ports or Aggregators in the system is being requested.
2个八位组。对应端口或聚合器的LACP参与者密钥。当此字段的值为0（端口号/聚合器ID字段也为0）时，表示正在请求系统中所有端口或聚合器的信息。
The "mLACP Synchronization Data TLV" is used in the "RG Application Data" message. A pair of these TLVs is used by a device to delimit a set of TLVs that are being transmitted in response to an "mLACP Synchronization Request TLV". The delimiting TLVs signal the start and end of the synchronization data and associate the response with its corresponding request via the "Request Number" field.
“RG应用程序数据”消息中使用“mLACP同步数据TLV”。设备使用一对TLV来限定响应“mLACP同步请求TLV”而传输的一组TLV。定界TLV向同步数据的开始和结束发送信号，并通过“请求编号”字段将响应与其相应的请求相关联。
The "mLACP Synchronization Data TLVs" are also used for unsolicited advertisements of complete mLACP configuration and operational state data. The "Request Number" field MUST be set to 0 in this case. For such unsolicited synchronization, the PE MUST advertise all system, Aggregator, and port information, as done during the initialization sequence.
“mLACP同步数据TLV”还用于完整mLACP配置和运行状态数据的非请求发布。在这种情况下，“请求编号”字段必须设置为0。对于这种未经请求的同步，PE必须公布所有系统、聚合器和端口信息，就像在初始化序列中所做的那样。
This TLV has the following format:
此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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0039 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0039 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U位和F位
Both are set to 0.
两者都设置为0。
- Type
- 类型
Set to 0x0039 for "mLACP Synchronization Data TLV".
“mLACP同步数据TLV”设置为0x0039。
- Length
- 长
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
TLV的长度（以八位字节为单位），不包括“U位”、“F位”、“类型”和“长度”字段。
- Request Number
- 请求号码
2 octets. Unsigned integer identifying the Request Number from the "mLACP Synchronization Request TLV" that solicited this synchronization data response.
2个八位组。标识请求此同步数据响应的“mLACP同步请求TLV”中的请求号的无符号整数。
- Flags
- 旗帜
2 octets. Response flags, encoded as follows:
2个八位组。响应标志，编码如下：
0x00 Synchronization Data Start 0x01 Synchronization Data End
0x00同步数据开始0x01同步数据结束
As required in [RFC5561], the following TLV is defined to indicate the ICCP capability:
根据[RFC5561]的要求，定义了以下TLV以指示ICCP能力：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TLV Code Point = 0x0700 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved | Ver/Maj | Ver/Min |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TLV Code Point = 0x0700 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved | Ver/Maj | Ver/Min |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- U形位
SHOULD be 1 (ignore if not understood).
应为1（如果不理解，则忽略）。
- F-bit
- F位
SHOULD be 0 (don't forward if not understood).
应为0（如果未理解，请不要转发）。
- TLV Code Point
- TLV代码点
The TLV type, which identifies a specific capability. The ICCP code point is listed in Section 12 below.
TLV类型，用于标识特定能力。以下第12节列出了ICCP代码点。
- S-bit
- S位
State bit. Indicates whether the sender is advertising or withdrawing the ICCP capability. The State bit is used as follows:
状态位。指示发送方是在公布还是正在撤回ICCP功能。状态位的使用方式如下：
1 - The TLV is advertising the capability specified by the TLV Code Point.
1-TLV正在宣传TLV代码点指定的能力。
0 - The TLV is withdrawing the capability specified by the TLV Code Point.
0-TLV正在撤回TLV代码点指定的功能。
- Ver/Maj
- 高级/专业
The major version revision of ICCP. This document specifies 1.0, and so this field is set to 1.
ICCP的主要版本修订。此文档指定1.0，因此此字段设置为1。
- Ver/Min
- 每分钟
The minor version revision of ICCP. This document specifies 1.0, and so this field is set to 0.
ICCP的次要版本修订。此文档指定1.0，因此此字段设置为0。
ICCP capability is advertised to an LDP peer if there is at least one RG enabled on the local PE.
如果本地PE上至少启用了一个RG，则向LDP对等方公布ICCP能力。
This section defines the procedures for the Pseudowire Redundancy (PW-RED) application.
本节定义了伪线冗余（PW-RED）应用程序的程序。
It should be noted that the PW-RED application SHOULD NOT be enabled together with an AC redundancy application for the same service instance. This simplifies the operation of the multi-chassis redundancy solution (Figure 1) and eliminates the possibility of deadlock conditions between the AC and PW redundancy mechanisms.
应注意，PW-RED应用程序不应与同一服务实例的AC冗余应用程序一起启用。这简化了多机箱冗余解决方案的操作（图1），并消除了AC和PW冗余机制之间出现死锁情况的可能性。
When an RG is configured on a system and multi-chassis pseudowire redundancy is enabled in that RG, the PW-RED application MUST send an "RG Connect" message with a "PW-RED Connect TLV" to each PE that is a member of the same RG. The sending PE MUST set the A-bit to 1 if it has already received a "PW-RED Connect TLV" from its peer; otherwise, the PE MUST set the A-bit to 0. If a PE that has sent the TLV with the A-bit set to 0 receives a "PW-RED Connect TLV" from a peer, it MUST repeat its advertisement with the A-bit set to 1. The PW-RED Application Connection is considered to be operational when both PEs have sent and received "PW-RED Connect TLVs" with the A-bit set to 1. Once the Application Connection becomes operational, the two devices can start exchanging "RG Application Data" messages for the PW-RED application.
在系统上配置RG且该RG中启用了多机箱伪线冗余时，PW-RED应用程序必须向属于同一RG的每个PE发送带有“PW-RED Connect TLV”的“RG Connect”消息。如果发送PE已从其对等方接收到“PW-RED Connect TLV”，则必须将A位设置为1；否则，PE必须将A位设置为0。如果发送a位设置为0的TLV的PE从对等方接收到“PW-RED Connect TLV”，则必须在a位设置为1的情况下重复其播发。当两个PE都发送和接收了A位设置为1的“PW-RED Connect TLV”时，PW-RED应用程序连接被认为是可操作的。一旦应用程序连接开始运行，两个设备就可以开始为PW-RED应用程序交换“RG应用程序数据”消息。
If a system receives an "RG Connect" message with a "PW-RED Connect TLV" that has a different Protocol Version, it must follow the procedures outlined in Section 4.4.1 above.
如果系统接收到带有不同协议版本的“PW-RED Connect TLV”的“RG Connect”消息，则必须遵循上述第4.4.1节中概述的程序。
When the PW-RED application is disabled on the device or is unconfigured for the RG in question, the system MUST send an "RG Disconnect" message with a "PW-RED Disconnect TLV".
当设备上禁用PW-RED应用程序或未为相关RG配置PW-RED应用程序时，系统必须发送带有“PW-RED Disconnect TLV”的“RG Disconnect”消息。
A system MUST advertise its local PW configuration to other PEs that are members of the same RG. This allows the PEs to build a view of the redundant nodes and pseudowires that are protecting the same service instances. The advertisement MUST be initiated when the PW-RED Application Connection first comes up. To that end, the system sends "RG Application Data" messages with "PW-RED Config TLVs"
系统必须向属于同一RG的其他PE公布其本地PW配置。这允许PEs构建保护相同服务实例的冗余节点和伪线的视图。必须在PW-RED应用程序连接首次出现时启动播发。为此，系统发送带有“PW-RED配置TLV”的“RG应用程序数据”消息
as part of an unsolicited synchronization. A PE MUST use a pair of "PW-RED Synchronization Data TLVs" to delimit the set of TLVs that are being sent as part of this unsolicited advertisement.
作为主动同步的一部分。PE必须使用一对“PW-RED同步数据TLV”来限定作为此未经请求的广告的一部分发送的TLV集。
In the case of a configuration change, a PE MUST re-advertise the most up-to-date information for the affected pseudowires.
在配置更改的情况下，PE必须重新公布受影响伪线的最新信息。
As part of the configuration synchronization, a PE advertises the ROID associated with the pseudowire. This is used to correlate the pseudowires that are protecting each other on different PEs. A PE also advertises the configured PW redundancy mode. This can be one of the following four options: Master Mode, Slave Mode, Independent Mode, or Independent Mode with Request Switchover. If the received redundancy mode does not match the locally configured mode for the same ROID, then the PE MUST respond with an "RG Notification" message to reject the "PW-RED Config TLV". The PE MUST disable the associated local pseudowire until a satisfactory "PW-RED Config TLV" is received from the peer. This guarantees that device misconfiguration does not lead to network-wide problems (e.g., by creating forwarding loops). The PE SHOULD also raise an alarm to alert the operator. If a PE receives a "NAK TLV" for an advertised "PW-RED Config TLV", it MUST disable the associated pseudowire and SHOULD raise an alarm to alert the operator.
作为配置同步的一部分，PE播发与伪线关联的ROID。这用于关联在不同PE上相互保护的伪线。PE还播发配置的PW冗余模式。这可以是以下四个选项之一：主模式、从模式、独立模式或带请求切换的独立模式。如果接收到的冗余模式与同一ROID的本地配置模式不匹配，则PE必须响应“RG通知”消息以拒绝“PW-RED配置TLV”。PE必须禁用相关的本地伪线，直到从对等方收到令人满意的“PW-RED Config TLV”。这保证了设备配置错误不会导致网络范围的问题（例如，通过创建转发循环）。PE还应发出警报以提醒操作员。如果PE收到播发的“PW-RED配置TLV”的“NAK TLV”，则必须禁用相关的伪线，并应发出警报提醒操作员。
Furthermore, a PE advertises in its "PW-RED Config TLVs" a priority value that is used to determine the precedence of a given pseudowire to assume the active role in a redundant setup. A PE also advertises a Service Name that is global in the context of an RG and is used to identify which pseudowires belong to the same service. Finally, a PE also advertises the pseudowire identifier as part of this synchronization.
此外，PE在其“PW-RED Config TLV”中公布优先级值，该值用于确定给定伪线的优先级，以在冗余设置中承担活动角色。PE还公布在RG上下文中全局的服务名称，用于标识属于同一服务的伪线。最后，PE还作为同步的一部分播发伪线标识符。
PEs that are members of an RG synchronize pseudowire status for the purpose of identifying, on a per-ROID basis, which pseudowire will be actively used for forwarding and which pseudowire(s) will be placed in standby state.
属于RG synchronize pseudowire status的PE，用于在每个ROID的基础上识别哪些pseudowire将积极用于转发，哪些pseudowire将处于待机状态。
Synchronization of pseudowire status is done by sending the "PW-RED State TLV" whenever the pseudowire state changes on a PE. This includes changes to the local end as well as the remote end of the pseudowire.
每当PE上的伪线状态发生变化时，通过发送“PW-RED State TLV”来同步伪线状态。这包括对伪线的本地端和远程端的更改。
A PE may request that its peer retransmit previously advertised PW-RED state. This is useful, for instance, when the PE is recovering from a soft failure. To request such a retransmission, a PE MUST send a set of one or more "PW-RED Synchronization Request TLVs".
PE可以请求其对等方重新传输先前公布的PW-RED状态。例如，当PE从软故障中恢复时，这非常有用。为了请求这种重传，PE必须发送一组一个或多个“PW-RED同步请求TLV”。
A PE MUST respond to a "PW-RED Synchronization Request TLV" by sending the requested data in a set of one or more "PW-RED TLVs" delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs comprising the response MUST be ordered such that the "Synchronization Response TLV" with the "Synchronization Data Start" flag precedes the various other "PW-RED TLVs" encoding the requested data. These, in turn, MUST precede the "Synchronization Data TLV" with the "Synchronization Data End" flag. It is worth noting that the response may span multiple "RG Application Data" messages; however, the above TLV ordering MUST be retained across messages, and only a single pair of "Synchronization Data TLVs" must be used to delimit the response across all "Application Data" messages.
PE必须通过发送由一对“PW-RED同步数据TLV”分隔的一组或多个“PW-RED TLV”中的请求数据来响应“PW-RED同步请求TLV”。组成响应的TLV的顺序必须确保带有“同步数据开始”标志的“同步响应TLV”位于编码所请求数据的各种其他“PW-RED TLV”之前。反过来，它们必须在“同步数据TLV”之前加上“同步数据结束”标志。值得注意的是，响应可能跨越多个“RG应用程序数据”消息；但是，必须在消息之间保留上述TLV顺序，并且只有一对“同步数据TLV”必须用于在所有“应用程序数据”消息之间限定响应。
A PE MAY re-advertise its PW-RED state in an unsolicited manner. This is done by sending the appropriate Config and State TLVs delimited by a pair of "PW-RED Synchronization Data TLVs" and using a "Request Number" of 0.
私募股权机构可以主动重新宣传其PW-RED状态。这是通过发送由一对“PW-RED同步数据TLV”分隔的适当配置和状态TLV并使用“请求号”0来完成的。
While a PE has a pending synchronization request for a pseudowire or a service, it SHOULD silently ignore all TLVs for said pseudowire or service that are received prior to the synchronization response and that carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other pseudowires or services are to continue to be processed per normal procedures in the interim.
当PE对伪线或服务有挂起的同步请求时，它应该静默地忽略在同步响应之前接收到的、携带被请求的相同类型信息的所述伪线或服务的所有TLV。这将使系统免于更新最终将被同步响应覆盖的状态的负担。请注意，与其他伪线或服务相关的TLV将在过渡期间继续按照正常程序进行处理。
If a PE receives a synchronization request for a pseudowire or service that doesn't exist or is not known to the PE, then it MUST trigger an unsolicited synchronization of all pseudowire information (i.e., replay the initialization sequence).
如果PE收到不存在或不为PE所知的伪线或服务的同步请求，则必须触发所有伪线信息的非请求同步（即，重播初始化序列）。
In the subsections that follow, we describe the details of pseudowire status synchronization for each of the PW redundancy modes defined in [RFC6870].
在接下来的小节中，我们将详细介绍[RFC6870]中定义的每个PW冗余模式的伪线状态同步。
This section covers the operation in Independent Mode with or without Request Switchover capability.
本节介绍独立模式下的操作，包括或不包括请求切换功能。
In this mode, the operator must ensure that for a given RO the PW Priority values configured for all associated pseudowires on a given PE are collectively higher (or lower) than those configured on other PEs in the same RG. If this condition is not satisfied after the PEs have exchanged "PW-RED State TLVs", a PE MUST disable the associated pseudowire(s) and SHOULD raise an alarm to alert the operator. Note that the PW Priority MAY be the same as the PW Precedence as defined in [RFC6870].
在此模式下，操作员必须确保对于给定RO，为给定PE上的所有相关伪线配置的PW优先级值总体高于（或低于）相同RG中其他PE上配置的PW优先级值。如果在PEs交换“PW-RED状态TLV”后未满足此条件，则PE必须禁用相关的伪线，并应发出警报提醒操作员。注意，PW优先级可能与[RFC6870]中定义的PW优先级相同。
For a given RO, after all of the PEs in an RG have exchanged their "PW-RED State TLVs", the PE with the best PW Priority (i.e., least numeric value) advertises active Preferential Forwarding status in LDP on all of its associated pseudowires, whereas all other PEs in the RG advertise standby Preferential Forwarding status in LDP on their associated pseudowires.
对于给定的RO，在RG中的所有PE交换了它们的“PW-RED状态TLV”之后，具有最佳PW优先级（即，最小数值）的PE在其所有相关联的伪线上宣传LDP中的活动优先转发状态，而RG中的所有其他PE在其关联的伪线上在LDP中宣传备用优先转发状态。
If the service is VPWS, then only a single pseudowire per service will be selected for forwarding. This is the pseudowire that is independently advertised with active Preferential Forwarding status on both endpoints, as described in [RFC6870].
如果服务是VPWS，则每个服务将只选择一个伪线进行转发。如[RFC6870]所述，这是在两个端点上以活动优先转发状态独立播发的伪线。
If the service is VPLS, then one or multiple pseudowires per service will be selected for forwarding. These are the pseudowires that are independently advertised with active Preferential Forwarding status on both PW endpoints, as described in [RFC6870].
如果服务是VPLS，则每个服务将选择一个或多个伪线进行转发。如[RFC6870]中所述，这些是在两个PW端点上以活动优先转发状态独立播发的伪线。
In this mode, the operator must ensure that for a given RO the PW Priority values configured for all associated pseudowires on a given PE are collectively higher (or lower) than those configured on other PEs in the same RG. If this condition is not satisfied after the PEs have exchanged "PW-RED State TLVs", a PE MUST disable the associated pseudowire(s) and SHOULD raise an alarm to alert the operator. Note that the PW Priority MAY be the same as the PW Precedence as defined in [RFC6870]. In addition, the operator must ensure that for a given RO all of the PEs in the RG are consistently configured as Master or Slave.
在此模式下，操作员必须确保对于给定RO，为给定PE上的所有相关伪线配置的PW优先级值总体高于（或低于）相同RG中其他PE上配置的PW优先级值。如果在PEs交换“PW-RED状态TLV”后未满足此条件，则PE必须禁用相关的伪线，并应发出警报提醒操作员。注意，PW优先级可能与[RFC6870]中定义的PW优先级相同。此外，操作员必须确保对于给定的RO，RG中的所有PE始终配置为主或从。
In the context of a given RO, if the PEs in the RG are acting as Master, then the PE with the best PW Priority (i.e., least numeric value) advertises active Preferential Forwarding status in LDP on
在给定RO的上下文中，如果RG中的PE充当主设备，则具有最佳PW优先级（即，最小数值）的PE在上广播LDP中的活动优先转发状态
only a single pseudowire, following the procedures in Sections 5.2 and 6.2 of [RFC6870], whereas all of the other pseudowires on other PEs in the RG are advertised with standby Preferential Forwarding status in LDP.
按照[RFC6870]第5.2节和第6.2节中的程序，只有一条伪线，而RG中其他PE上的所有其他伪线在LDP中以备用优先转发状态进行广告。
When a PE node detects that a remote PE that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5), the local PE determines if it has redundant PWs for the affected services. If the local PE has the highest priority (after the failed PE), then it becomes the active node for the services in question and subsequently activates its associated PW(s).
当PE节点检测到作为同一RG成员的远程PE不再可访问时（使用第5节中描述的机制），本地PE确定其是否具有受影响服务的冗余PW。如果本地PE具有最高优先级（在失败的PE之后），则它将成为相关服务的活动节点，并随后激活其关联的PW。
This section describes generic procedures for AC redundancy applications, independent of the type of the AC (ATM, FR, or Ethernet).
本节描述了交流冗余应用的通用程序，和交流类型（ATM、FR或以太网）无关。
When the AC redundancy mechanism on the active PE detects a failure of the AC, it should send an ICCP "Application Data" message to inform the redundant PEs of the need to take over. The AC failures can be categorized into the following scenarios:
当活动PE上的AC冗余机制检测到AC故障时，应发送ICCP“应用数据”消息，通知冗余PE需要接管。交流故障可分为以下几种情况：
- Failure of CE interface connecting to PE
- 连接到PE的CE接口故障
- Failure of CE uplink to PE
- CE上行至PE的故障
- Failure of PE interface connecting to CE
- PE接口连接到CE的故障
When a PE node detects that a remote PE that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5), the local PE determines if it has redundant ACs for the affected services. If the local PE has the highest priority (after the failed PE), then it becomes the active node for the services in question and subsequently activates its associated ACs.
当PE节点检测到作为同一RG成员的远程PE不再可访问（使用第5节中描述的机制）时，本地PE确定其是否具有用于受影响服务的冗余ACs。如果本地PE具有最高优先级（在发生故障的PE之后），则它将成为相关服务的活动节点，并随后激活其关联的ACs。
When a PE node detects that it has been isolated from the core network (i.e., all core-facing interfaces/links are not operational), then it should ensure that its AC redundancy mechanism will change the status of any active ACs to standby. The AC redundancy application SHOULD then send ICCP "Application Data" messages in order to trigger failover to a standby PE. Note that this works only in the case of dedicated interconnect (Sections 3.2.1 and 3.2.3), since ICCP will still have a path to the peer, even though the PE is isolated from the MPLS core network.
当PE节点检测到其已与核心网络隔离（即，所有面向核心的接口/链路均不工作）时，应确保其AC冗余机制将任何活动AC的状态更改为备用。然后，AC冗余应用程序应发送ICCP“应用程序数据”消息，以便触发到备用PE的故障切换。请注意，这仅适用于专用互连（第3.2.1节和第3.2.3节），因为即使PE与MPLS核心网络隔离，ICCP仍将具有到对等方的路径。
If the PEs in an RG are running an AC redundancy application over ICCP, then the Independent Mode of PW redundancy, as defined in [RFC6870], MUST be used. On a given PE, the Preferential Forwarding status of the PW (active or standby) is derived from the state of the associated AC(s). This simplifies the operation of the multi-chassis redundancy solution (Figure 1) and eliminates the possibility of deadlock conditions between the AC and PW redundancy mechanisms. The rules by which the PW status is derived from the AC status are as follows:
如果RG中的PEs通过ICCP运行交流冗余应用程序，则必须使用[RFC6870]中定义的PW冗余独立模式。在给定的PE上，PW的优先转发状态（活动或备用）来自相关AC的状态。这简化了多机箱冗余解决方案的操作（图1），并消除了AC和PW冗余机制之间出现死锁情况的可能性。从交流状态导出PW状态的规则如下：
- VPWS
- VPWS
For VPWS, there's a single AC per service instance. If the AC is active, then the PW status should be active. If the AC is standby, then the PW status should be standby.
对于VPWS，每个服务实例只有一个AC。如果AC为激活状态，则PW状态应为激活状态。如果AC为备用，则PW状态应为备用。
- VPLS
- VPLS
For VPLS, there could be multiple ACs per service instance (i.e., Virtual Switch Instance (VSI) [RFC4026]). If AT LEAST ONE AC is active, then the PW status should be active. If ALL ACs are standby, then the PW status should be standby.
对于VPL，每个服务实例（即虚拟交换机实例（VSI）[RFC4026]）可能有多个ACs。如果至少有一个AC处于激活状态，则PW状态应为激活状态。如果所有ACs都处于待机状态，则PW状态应为待机状态。
In this case, the PW-RED application is not used to synchronize PW status between PEs. Rather, the AC redundancy application should synchronize AC status between PEs, in order to establish which AC (and subsequently which PE) is active or standby for a given service. When that is determined, each PE will then derive its local PW's state according to the rules described above. The Preferential Forwarding status bit, described in [RFC6870], is used to advertise PW status to the remote peers.
在这种情况下，PW-RED应用程序不用于同步PEs之间的PW状态。相反，AC冗余应用程序应该同步PEs之间的AC状态，以便确定给定服务的哪个AC（以及随后哪个PE）是活动的还是备用的。确定后，每个PE将根据上述规则导出其本地PW的状态。[RFC6870]中描述的优先转发状态位用于向远程对等方通告PW状态。
This section defines the procedures that are specific to the multi-chassis LACP (mLACP) application, which is applicable for Ethernet ACs.
本节定义了适用于以太网ACs的多机箱LACP（mLACP）应用程序的特定程序。
When an RG is configured on a system and mLACP is enabled in that RG, the mLACP application MUST send an "RG Connect" message with an "mLACP Connect TLV" to each PE that is a member of the same RG. The sending PE MUST set the A-bit to 1 in said TLV if it has received a corresponding "mLACP Connect TLV" from its peer PE; otherwise, the sending PE MUST set the A-bit to 0. If a PE receives an "mLACP Connect TLV" from its peer after sending said TLV with the A-bit set to 0, it MUST resend the TLV with the A-bit set to 1. A system considers the mLACP Application Connection to be operational when it has sent and received "mLACP Connect TLVs" with the A-bit set to 1. When the mLACP Application Connection between a pair of PEs is operational, the two devices can start exchanging "RG Application Data" messages for the mLACP application. This involves having each PE advertise its mLACP configuration and operational state in an unsolicited manner. A PE SHOULD use the following sequence when advertising its mLACP state upon initial Application Connection setup:
当在系统上配置RG并且在该RG中启用mLACP时，mLACP应用程序必须向属于同一RG成员的每个PE发送带有“mLACP Connect TLV”的“RG Connect”消息。如果发送PE已从其对等PE接收到相应的“mLACP Connect TLV”，则发送PE必须将所述TLV中的A位设置为1；否则，发送PE必须将A位设置为0。如果PE在发送a位设置为0的所述TLV后从其对等方接收到“mLACP Connect TLV”，则必须重新发送a位设置为1的TLV。当系统发送和接收A位设置为1的“mLACP Connect TLV”时，系统认为mLACP应用程序连接可运行。当一对PEs之间的mLACP应用程序连接运行时，两个设备可以开始为mLACP应用程序交换“RG应用程序数据”消息。这涉及到让每个PE以未经请求的方式公布其mLACP配置和操作状态。PE在初始应用程序连接设置时公布其mLACP状态时应使用以下顺序：
- Advertise system configuration
- 公布系统配置
- Advertise Aggregator configuration
- 播发聚合器配置
- Advertise port configuration
- 播发端口配置
- Advertise Aggregator state
- 播发聚合器状态
- Advertise port state
- 宣传港口国
A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit the entire set of TLVs that are being sent as part of this unsolicited advertisement.
PE必须使用一对“mLACP同步数据TLV”来界定作为此未经请求的公告的一部分发送的整个TLV集。
If a system receives an "RG Connect" message with an "mLACP Connect TLV" that has a different Protocol Version, it MUST follow the procedures outlined in Section 4.4.1 above.
如果系统收到带有“mLACP Connect TLV”且具有不同协议版本的“RG Connect”消息，则必须遵循上述第4.4.1节中概述的程序。
After the mLACP Application Connection has been established, every PE MUST communicate its system-level configuration to its peers via the use of the "mLACP System Config TLV". This allows every PE to discover the Node ID and the locally configured System ID and System Priority values of its peers.
建立mLACP应用程序连接后，每个PE必须使用“mLACP系统配置TLV”将其系统级配置与其对等方进行通信。这允许每个PE发现节点ID和本地配置的系统ID以及其对等方的系统优先级值。
If a PE receives an "mLACP System Config TLV" from a remote peer advertising the same Node ID value as the local system, then the PE MUST respond with an "RG Notification" message to reject the "mLACP System Config TLV". The PE MUST suspend the mLACP application until a satisfactory "mLACP System Config TLV" is received from the peer. It SHOULD also raise an alarm to alert the operator. Furthermore, if a PE receives a "NAK TLV" for an "mLACP System Config TLV" that it has advertised, the PE MUST suspend the mLACP application and SHOULD raise an alarm to alert the network operator of potential device misconfiguration.
如果PE从远程对等方接收到“mLACP系统配置TLV”，通知与本地系统相同的节点ID值，则PE必须响应“RG通知”消息以拒绝“mLACP系统配置TLV”。PE必须暂停mLACP应用程序，直到从对等方收到令人满意的“mLACP系统配置TLV”。它还应发出警报，提醒操作员。此外，如果PE接收到其已发布的“mLACP系统配置TLV”的“NAK TLV”，则PE必须暂停mLACP应用程序，并应发出警报，以提醒网络运营商潜在的设备配置错误。
If a PE receives an "mLACP System Config TLV" from a new peer advertising the same Node ID value as another existing peer with which the local system has an established mLACP Application Connection, then the PE MUST respond to the new peer with an "RG Notification" message to reject the "mLACP System Config TLV" and MUST ignore the offending TLV.
如果PE从一个新的对等方接收到一个“mLACP系统配置TLV”，该对等方公布的节点ID值与本地系统已建立mLACP应用程序连接的另一个现有对等方相同，则PE必须使用“RG通知”消息响应新对等方，以拒绝“mLACP系统配置TLV”，并且必须忽略有问题的TLV。
If the Node ID of a particular PE changes due to administrative configuration action, the PE MUST then inform its peers to purge the configuration of all previously advertised ports and/or Aggregators and MUST replay the initialization sequence by sending an unsolicited synchronization of the system configuration, Aggregator configuration, port configuration, Aggregator state, and port state.
如果特定PE的节点ID因管理配置操作而更改，则PE必须通知其对等方清除所有先前播发的端口和/或聚合器的配置，并且必须通过发送系统配置、聚合器配置的非请求同步来重播初始化序列，端口配置、聚合器状态和端口状态。
It is necessary for all PEs in an RG to agree upon the System ID and System Priority values to be used ubiquitously. To achieve this, every PE MUST use the values for the two parameters that are supplied by the PE with the numerically lowest value (among RG members) of System Aggregation Priority. This guarantees that the PEs always agree on uniform values that yield the highest System Priority.
RG中的所有PE都必须就普遍使用的系统ID和系统优先级值达成一致。为了实现这一点，每个PE必须使用PE提供的两个参数的值，这两个参数具有系统聚合优先级的数字最低值（RG成员中）。这保证了PEs始终同意产生最高系统优先级的统一值。
When the mLACP application is disabled on the device or is unconfigured for the RG in question, the system MUST send an "RG Disconnect" message with an "mLACP Disconnect TLV".
当设备上禁用mLACP应用程序或未针对相关RG配置mLACP应用程序时，系统必须发送带有“mLACP Disconnect TLV”的“RG Disconnect”消息。
A system MUST synchronize the configuration of its mLACP-enabled Aggregators and ports with other RG members. This is achieved via the use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", respectively. An implementation MUST advertise the configuration of Aggregators prior to advertising the configuration of any of their associated member ports.
系统必须将其启用mLACP的聚合器和端口的配置与其他RG成员同步。这是通过分别使用“mLACP聚合器配置TLV”和“mLACP端口配置TLV”实现的。实现必须在公布聚合器的任何关联成员端口的配置之前公布聚合器的配置。
The PEs in an RG MUST all agree on the MAC address to be associated with a given Aggregator. It is possible to achieve this via consistent configuration on member PEs. However, in order to protect against possible misconfiguration, a system MUST use, for any given Aggregator, the MAC address supplied by the PE with the numerically lowest System Aggregation Priority in the RG.
RG中的PE必须一致同意与给定聚合器关联的MAC地址。通过成员PE上的一致配置，可以实现这一点。然而，为了防止可能的错误配置，对于任何给定的聚合器，系统必须使用PE提供的MAC地址，该地址在RG中具有数字上最低的系统聚合优先级。
A system that receives an "mLACP Aggregator Config TLV" with an ROID-to-Key association that is different from its local association MUST reject the corresponding TLV and disable the Aggregator with the same ROID. Furthermore, it SHOULD raise an alarm to alert the operator. Similarly, a system that receives a "NAK TLV" in response to a transmitted "mLACP Aggregator Config TLV" MUST disable the associated Aggregator and SHOULD raise an alarm to alert the network operator.
接收“mLACP聚合器配置TLV”且ROID与密钥关联与其本地关联不同的系统必须拒绝相应的TLV并禁用具有相同ROID的聚合器。此外，还应发出警报，提醒操作员。类似地，接收“NAK TLV”以响应传输的“mLACP聚合器配置TLV”的系统必须禁用相关聚合器，并应发出警报以提醒网络运营商。
A system MAY enforce a restriction that all ports that are to be bundled together on a given PE share the same Port Priority value. If so, the system MUST advertise this common priority in the "mLACP Aggregator Config TLV" and assert the "Priority Set" flag in that TLV. Furthermore, the system in this case MUST NOT advertise individual Port Priority values in the associated "mLACP Port Config TLVs" (i.e., the "Priority Set" flag in these TLVs should be 0).
系统可以强制执行一个限制，即在给定PE上捆绑在一起的所有端口共享相同的端口优先级值。如果是这样，系统必须在“mLACP聚合器配置TLV”中公布此公共优先级，并在该TLV中断言“优先级设置”标志。此外，在这种情况下，系统不得在关联的“mLACP端口配置TLV”中公布单个端口优先级值（即，这些TLV中的“优先级设置”标志应为0）。
A system MAY support individual Port Priority values to be configured on ports that are to be bundled together on a PE. If so, the system MUST advertise the individual Port Priority values in the appropriate "mLACP Port Config TLVs" and MUST NOT assert the "Priority Set" flag in the corresponding "mLACP Aggregator Config TLV".
系统可以支持在PE上捆绑在一起的端口上配置的各个端口优先级值。如果是这样，系统必须在相应的“mLACP端口配置TLV”中公布各个端口优先级值，并且不得在相应的“mLACP聚合器配置TLV”中断言“优先级设置”标志。
When the configurations of all ports for member links associated with a given Aggregator have been sent by a device, it asserts that fact by setting the "Synchronized" flag in the last port's "mLACP Port Config TLV". If an Aggregator doesn't have any candidate member ports configured, this is indicated by asserting the "Synchronized" flag in its "mLACP Aggregator Config TLV".
当设备已发送与给定聚合器关联的成员链接的所有端口的配置时，它通过在最后一个端口的“mLACP端口配置TLV”中设置“Synchronized”标志来确认这一事实。如果聚合器未配置任何候选成员端口，则通过在其“mLACP聚合器配置TLV”中断言“已同步”标志来指示。
Furthermore, for a given port/Aggregator, an implementation MUST advertise the port/Aggregator configuration prior to advertising its state (via the "mLACP Port State TLV" or "mLACP Aggregator State
此外，对于给定的端口/聚合器，实现必须在公布其状态之前公布端口/聚合器配置（通过“mLACP端口状态TLV”或“mLACP聚合器状态
TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP Aggregator State TLV" for a port or Aggregator that it had not previously learned via an appropriate "Port Config TLV" or "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all mLACP ports as well as all mLACP Aggregators from its respective peer. During a synchronization (solicited or unsolicited), if a PE receives a "State TLV" for a port or Aggregator that it has not learned before, then the PE MUST send a "NAK TLV" for the offending TLV. The PE MUST NOT request resynchronization in this case.
TLV”）。如果PE接收到端口或聚合器的“mLACP端口状态TLV”或“mLACP聚合器状态TLV”，则其先前未通过适当的“端口配置TLV”或“聚合器配置TLV”获知该端口或聚合器，则PE必须从其各自的对等方请求同步所有mLACP端口以及所有mLACP聚合器的配置和状态。在同步过程中（请求或非请求），如果PE接收到其之前未获悉的端口或聚合器的“状态TLV”，则PE必须为有问题的TLV发送“NAK TLV”。在这种情况下，PE不得请求重新同步。
When mLACP is unconfigured on a port/Aggregator, a PE MUST send a "Port/Aggregator Config TLV" with the "Purge Configuration" flag asserted. This allows receiving PEs to purge any state maintained for the decommissioned port/Aggregator. If a PE receives a "Port/Aggregator Config TLV" with the "Purge Configuration" flag asserted and the PE is not maintaining any state for that port/Aggregator, then it MUST silently discard the TLV.
当在端口/聚合器上未配置mLACP时，PE必须发送“端口/聚合器配置TLV”，并声明“清除配置”标志。这允许接收PEs清除为停用端口/聚合器维护的任何状态。如果PE接收到一个“端口/聚合器配置TLV”，并且声明了“清除配置”标志，并且PE没有维护该端口/聚合器的任何状态，那么它必须以静默方式放弃TLV。
PEs within an RG need to synchronize their state machines for proper mLACP operation with a multi-homed device. This is achieved by having each system advertise its Aggregators and ports running state in "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", respectively. Whenever any LACP parameter for an Aggregator or a port -- whether on the Partner (i.e., multi-homed device) side or the Actor (i.e., PE) side -- is changed, a system MUST transmit an updated TLV for the affected Aggregator and/or port. Moreover, when the administrative or operational state of an Aggregator or port changes, the system MUST transmit an updated Aggregator or Port State TLV to its peers.
RG内的PE需要将其状态机与多宿设备同步，以实现正确的mLACP操作。这是通过让每个系统分别在“mLACP聚合器状态TLV”和“mLACP端口状态TLV”中公布其聚合器和端口的运行状态来实现的。无论何时更改聚合器或端口的任何LACP参数（无论是在伙伴（即多宿主设备）端还是参与者（即PE）端），系统都必须为受影响的聚合器和/或端口发送更新的TLV。此外，当聚合器或端口的管理或操作状态发生更改时，系统必须将更新的聚合器或端口状态TLV传输给其对等方。
If a PE receives an Aggregator or Port State TLV where the Actor Key doesn't match what was previously received in a corresponding "Aggregator Config TLV" or "Port Config TLV", the PE MUST then request synchronization of the configuration and state of the affected Aggregator or port. If such a mismatch occurs between the Config and State TLVs as part of a synchronization (solicited or unsolicited), then the PE MUST send a "NAK TLV" for the "State TLV". Furthermore, if a PE receives a "Port State TLV" with the "Aggregator ID" set to a value that doesn't map to some Aggregator that the PE had learned via a previous "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all Aggregators and ports. If the above anomaly occurs during a synchronization, then the PE MUST send a "NAK TLV" for the offending "Port State TLV".
如果PE接收到聚合器或端口状态TLV，而参与者密钥与之前在相应的“聚合器配置TLV”或“端口配置TLV”中接收到的不匹配，则PE必须请求同步受影响聚合器端口的配置和状态。如果作为同步（请求或非请求）的一部分，配置和状态TLV之间发生这种不匹配，则PE必须为“状态TLV”发送“NAK TLV”。此外，如果PE接收到一个“端口状态TLV”，且“聚合器ID”设置为一个值，该值未映射到PE通过以前的“聚合器配置TLV”学习到的某个聚合器，则PE必须请求同步所有聚合器和端口的配置和状态。如果在同步过程中发生上述异常，则PE必须为有问题的“端口状态TLV”发送“NAK TLV”。
A PE MAY request that its peer retransmit previously advertised state. This is useful, for example, when the PE is recovering from a soft failure and attempting to relearn state. To request such retransmissions, a PE MUST send a set of one or more "mLACP Synchronization Request TLVs".
PE可以请求其对等方重新传输先前公布的状态。例如，当PE从软故障中恢复并尝试重新学习状态时，这非常有用。要请求此类重传，PE必须发送一组一个或多个“mLACP同步请求TLV”。
A PE MUST respond to an "mLACP Synchronization Request TLV" by sending the requested data in a set of one or more mLACP TLVs delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs comprising the response MUST be ordered in the "RG Application Data" message(s) such that the "Synchronization Response TLV" with the "Synchronization Data Start" flag precedes the various other mLACP TLVs encoding the requested data. These, in turn, MUST precede the "Synchronization Data TLV" with the "Synchronization Data End" flag. Note that the response may span multiple "RG Application Data" messages -- for example, when MTU limits are exceeded; however, the above ordering MUST be retained across messages, and only a single pair of "Synchronization Data TLVs" MUST be used to delimit the response across all "Application Data" messages.
PE必须通过发送由一对“mLACP同步数据TLV”分隔的一组或多个mLACP TLV中的请求数据来响应“mLACP同步请求TLV”。包含响应的TLV必须在“RG应用程序数据”消息中排序，以便带有“同步数据开始”标志的“同步响应TLV”位于编码所请求数据的各种其他mLACP TLV之前。反过来，它们必须在“同步数据TLV”之前加上“同步数据结束”标志。注意，响应可能跨越多个“RG应用程序数据”消息——例如，当超过MTU限制时；但是，必须在消息之间保留上述顺序，并且只有一对“同步数据TLV”必须用于在所有“应用程序数据”消息之间限定响应。
A PE device MAY re-advertise its mLACP state in an unsolicited manner. This is done by sending the appropriate Config and State TLVs delimited by a pair of "mLACP Synchronization Data TLVs" and using a "Request Number" of 0.
PE设备可以以未经请求的方式重新公布其mLACP状态。这是通过发送由一对“mLACP同步数据TLV”分隔的适当配置和状态TLV并使用“请求号”0来完成的。
While a PE has a pending synchronization request for a system, Aggregator, or port, it SHOULD silently ignore all TLVs for said system, Aggregator, or port that are received prior to the synchronization response and that carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other systems, Aggregators, or ports are to continue to be processed per normal procedures in this case.
当PE对系统、聚合器或端口有一个挂起的同步请求时，它应该静默地忽略在同步响应之前接收到的所述系统、聚合器或端口的所有TLV，并且这些TLV携带被请求的相同类型的信息。这将使系统免于更新最终将被同步响应覆盖的状态的负担。请注意，在这种情况下，与其他系统、聚合器或端口相关的TLV将继续按照正常过程进行处理。
If a PE receives a synchronization request for an Aggregator, port, or key that doesn't exist or is not known to the PE, then it MUST trigger an unsolicited synchronization of all system, Aggregator, and port information (i.e., replay the initialization sequence).
如果PE收到不存在或PE不知道的聚合器、端口或密钥的同步请求，则必须触发所有系统、聚合器和端口信息的非请求同步（即，重播初始化序列）。
If a PE learns, as part of a synchronization operation from its peer, that the latter is advertising a Node ID value that is different from the value previously advertised, then the PE MUST purge all Port/Aggregator data previously learned from that peer prior to the last synchronization.
如果作为同步操作的一部分，PE从其对等方获悉后者正在公布与先前公布的值不同的节点ID值，则PE必须在上次同步之前清除先前从该对等方获悉的所有端口/聚合器数据。
When a PE that is active for a multi-chassis link aggregation group encounters a core isolation fault, it SHOULD attempt to fail over to a peer PE that hosts the same RO. The default failover procedure is to have the failed PE bring down the link or links towards the multi-homed CE (e.g., by bringing down the line protocol). This will cause the CE to fail over to the other member link or links of the bundle that are connected to the other PE(s) in the RG. Other procedures for triggering failover are possible; such procedures are outside the scope of this document.
当多机箱链路聚合组的活动PE遇到核心隔离故障时，它应尝试故障转移到承载相同RO的对等PE。默认故障切换过程是让故障PE断开指向多宿CE的一条或多条链路（例如，通过断开线路协议）。这将导致CE故障转移到连接到RG中其他PE的捆绑包的其他成员链路。触发故障转移的其他过程是可能的；此类程序不在本文件范围内。
Upon recovery from a previous fault, a PE MAY reclaim the active role for a multi-chassis link aggregation group if configured for revertive protection. Otherwise, the recovering PE may assume the standby role when configured for non-revertive protection. In the revertive scenario, a PE SHOULD assume the active role within the RG by sending an "mLACP Port Priority TLV" to the currently active PE, requesting that the latter change its port priority to a value that is lower (i.e., numerically larger) for the Aggregator in question.
从以前的故障恢复后，如果配置为恢复保护，则PE可以为多机箱链路聚合组回收活动角色。否则，当配置为非恢复性保护时，恢复PE可能承担备用角色。在还原场景中，PE应通过向当前活动PE发送“mLACP端口优先级TLV”来承担RG内的活动角色，请求当前活动PE将其端口优先级更改为相关聚合器的较低（即数值较大）的值。
If a system is operating in a mode where different ports of a bundle are configured with different Port Priorities, then the system MUST NOT advertise or request changes of Port Priority values for aggregated ports collectively (i.e., by using a "Port Number" of 0 in the "mLACP Port Priority TLV"). This is to avoid ambiguity in the interpretation of the "Last Port Priority" field.
如果系统在捆绑包的不同端口配置了不同的端口优先级的模式下运行，则系统不得共同公布或请求更改聚合端口的端口优先级值（即，通过在“mLACP端口优先级TLV”中使用0的“端口号”）。这是为了避免在解释“最后一个端口优先级”字段时出现歧义。
If a PE receives an "mLACP Port Priority TLV" requesting a priority change for a port or Aggregator that is not local to the device, then the PE MUST re-advertise the local configuration of the system, as well as the configuration and state of all of its mLACP ports and Aggregators.
如果PE接收到“mLACP端口优先级TLV”，请求更改设备非本地端口或聚合器的优先级，则PE必须重新公布系统的本地配置，以及其所有mLACP端口和聚合器的配置和状态。
If a PE receives an "mLACP Port Priority TLV" in which the remote system is advertising priority change for a port or Aggregator that the local PE had not previously learned via an appropriate "Port Config TLV" or "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all mLACP ports as well as all mLACP Aggregators from its respective peer.
如果PE接收到“mLACP端口优先级TLV”，其中远程系统正在播发本地PE以前未通过适当的“端口配置TLV”或“聚合器配置TLV”了解到的端口或聚合器的优先级更改，然后，PE必须从其各自的对等方请求所有mLACP端口以及所有mLACP聚合器的配置和状态的同步。
ICCP SHOULD only be used in well-managed and highly monitored networks. It ought not be deployed on or over the public Internet. ICCP is not intended to be applicable when the Redundancy Group spans PEs in different administrative domains.
ICCP应仅用于管理良好和高度监控的网络。它不应该部署在公共互联网上。当冗余组跨越不同管理域中的PEs时，ICCP不适用。
The security considerations described in [RFC5036] and [RFC4447] that apply to the base LDP specification and to the PW LDP control protocol extensions apply to the capability mechanism described in this document. In particular, ICCP implementations MUST provide a mechanism to select to which LDP peers the ICCP capability will be advertised, and from which LDP peers the ICCP messages will be accepted. Therefore, an incoming ICCP connection request MUST NOT be accepted unless its source IP address is known to be the source of an "eligible" ICCP peer. The set of eligible peers could be preconfigured (as a list of either IP addresses or address/mask combinations), or it could be discovered dynamically via some secure discovery protocol. The TCP Authentication Option (TCP-AO), as defined in [RFC5925], SHOULD be used. This provides integrity and authentication for the ICCP messages and eliminates the possibility of source address spoofing. However, for backwards compatibility and/or to accommodate the ease of migration, the LDP MD5 authentication key option, as described in Section 2.9 of [RFC5036], MAY be used instead.
[RFC5036]和[RFC4447]中描述的适用于基本LDP规范和PW LDP控制协议扩展的安全注意事项适用于本文件中描述的能力机制。特别是，ICCP实现必须提供一种机制，以选择ICCP能力将向哪个LDP对等方公布，以及ICCP消息将从哪个LDP对等方接受。因此，除非已知传入ICCP连接请求的源IP地址是“合格”ICCP对等方的源，否则不得接受该请求。可以预先配置一组合格的对等点（作为IP地址或地址/掩码组合的列表），也可以通过某种安全发现协议动态发现。应使用[RFC5925]中定义的TCP身份验证选项（TCP-AO）。这为ICCP消息提供了完整性和身份验证，并消除了源地址欺骗的可能性。但是，为了向后兼容和/或适应迁移的便利性，可以使用[RFC5036]第2.9节所述的LDP MD5认证密钥选项。
The security framework and considerations for MPLS in general, and LDP in particular, as described in [RFC5920] apply to this document. Moreover, the recommendations of [RFC6952] and mechanisms of [LDP-CRYPTO] aimed at addressing LDP's vulnerabilities are applicable as well.
[RFC5920]中所述的MPLS（尤其是LDP）的安全框架和注意事项适用于本文件。此外，[RFC6952]的建议和旨在解决LDP漏洞的[LDP-CRYPTO]机制也适用。
Furthermore, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. For example, a malicious CE implementation may trigger continuously varying LACP messages that lead to excessive ICCP exchanges. Also, excessive link bouncing of the attachment circuits may lead to the same effect. Similar arguments apply to the inter-PE MPLS links. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate these types of attacks.
此外，连接电路上的活动可能会造成安全威胁或被利用来创建拒绝服务攻击。例如，恶意CE实现可能会触发不断变化的LACP消息，从而导致过度ICCP交换。此外，附件电路的过度链路反弹可能会导致相同的效果。类似的参数适用于PE间MPLS链路。实现应提供执行控制平面监控和缓解这些类型攻击的机制。
Implementations SHOULD generally minimize the number of parameters required to configure ICCP in order to help make ICCP easier to use. Implementations SHOULD allow the user to control the RGID via configuration, as this is required to support flexible grouping of PEs in RGs. Furthermore, implementations SHOULD provide mechanisms to troubleshoot the correct operation of ICCP; this includes providing mechanisms to diagnose ICCP connections as well as Application Connections. Implementations MUST provide a means for the user to indicate the IP addresses of remote PEs that are to be members of a given RG. Automatic discovery of RG membership MAY be supported; this topic is outside the scope of this specification.
实施通常应尽量减少配置ICCP所需的参数数量，以帮助使ICCP更易于使用。实施应允许用户通过配置控制RGID，因为这是支持RGs中PE灵活分组所必需的。此外，实施应提供解决ICCP正确运行问题的机制；这包括提供诊断ICCP连接以及应用程序连接的机制。实施必须为用户提供一种方法，以指示将成为给定RG成员的远程PE的IP地址。可能支持自动发现RG成员资格；本主题不在本规范的范围内。
This document uses several new LDP message types. IANA maintains the "Message Type Name Space" registry as defined by [RFC5036]. The following values have been assigned:
本文档使用了几种新的LDP消息类型。IANA维护[RFC5036]定义的“消息类型名称空间”注册表。已指定以下值：
Message Type Description
------------- ----------------------------
0x0700 RG Connect Message
0x0701 RG Disconnect Message
0x0702 RG Notification Message
0x0703 RG Application Data Message
0x0704-0x070F Reserved for future ICCP use
Message Type Description
------------- ----------------------------
0x0700 RG Connect Message
0x0701 RG Disconnect Message
0x0702 RG Notification Message
0x0703 RG Application Data Message
0x0704-0x070F Reserved for future ICCP use
This document uses a new LDP TLV type. IANA maintains the "TLV Type Name Space" registry as defined by [RFC5036]. The following value has been assigned:
本文件使用新的LDP TLV类型。IANA维护[RFC5036]定义的“TLV类型名称空间”注册表。已指定以下值：
TLV Type Description
-------- -------------------
0x0700 ICCP capability TLV
TLV Type Description
-------- -------------------
0x0700 ICCP capability TLV
IANA has created a registry called "ICC RG Parameter Types", within the "Pseudowire Name Spaces (PWE3)" registry. ICC RG parameter types are 14-bit values. Parameter Type values 1 through 0x003A are specified in this document. Parameter Type values 0x003B through 0x1FFF are to be assigned by IANA, using the "Expert Review" policy defined in [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 are to be allocated using the "IETF Review" policy defined in [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved for vendor proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in [RFC5226].
IANA在“伪线名称空间（PWE3）”注册表中创建了一个名为“ICC RG参数类型”的注册表。ICC RG参数类型为14位值。本文件中规定了参数类型值1至0x003A。IANA将使用[RFC5226]中定义的“专家评审”策略分配参数类型值0x003B至0x1FF。参数类型值0x2000到0x2FF、0x3FFF和0将使用[RFC5226]中定义的“IETF审查”策略进行分配。参数类型值0x3000到0x3FFE为供应商专有扩展保留，由IANA使用[RFC5226]中定义的“先到先得”策略分配。
Initial ICC parameter type space value allocations are specified below:
初始ICC参数类型空间值分配规定如下：
Parameter Type Description
-------------- ----------------------------------
0x0001 ICC Sender Name
0x0002 NAK TLV
0x0003 Requested Protocol Version TLV
0x0004 Disconnect Code TLV
0x0005 ICC RG ID TLV
0x0006-0x000F Reserved
0x0010 PW-RED Connect TLV
0x0011 PW-RED Disconnect TLV
0x0012 PW-RED Config TLV
0x0013 Service Name TLV
0x0014 PW ID TLV
0x0015 Generalized PW ID TLV
0x0016 PW-RED State TLV
0x0017 PW-RED Synchronization Request TLV
0x0018 PW-RED Synchronization Data TLV
0x0019 PW-RED Disconnect Cause TLV
0x001A-0x002F Reserved
0x0030 mLACP Connect TLV
0x0031 mLACP Disconnect TLV
0x0032 mLACP System Config TLV
0x0033 mLACP Port Config TLV
0x0034 mLACP Port Priority TLV
0x0035 mLACP Port State TLV
0x0036 mLACP Aggregator Config TLV
0x0037 mLACP Aggregator State TLV
0x0038 mLACP Synchronization Request TLV
0x0039 mLACP Synchronization Data TLV
0x003A mLACP Disconnect Cause TLV
Parameter Type Description
-------------- ----------------------------------
0x0001 ICC Sender Name
0x0002 NAK TLV
0x0003 Requested Protocol Version TLV
0x0004 Disconnect Code TLV
0x0005 ICC RG ID TLV
0x0006-0x000F Reserved
0x0010 PW-RED Connect TLV
0x0011 PW-RED Disconnect TLV
0x0012 PW-RED Config TLV
0x0013 Service Name TLV
0x0014 PW ID TLV
0x0015 Generalized PW ID TLV
0x0016 PW-RED State TLV
0x0017 PW-RED Synchronization Request TLV
0x0018 PW-RED Synchronization Data TLV
0x0019 PW-RED Disconnect Cause TLV
0x001A-0x002F Reserved
0x0030 mLACP Connect TLV
0x0031 mLACP Disconnect TLV
0x0032 mLACP System Config TLV
0x0033 mLACP Port Config TLV
0x0034 mLACP Port Priority TLV
0x0035 mLACP Port State TLV
0x0036 mLACP Aggregator Config TLV
0x0037 mLACP Aggregator State TLV
0x0038 mLACP Synchronization Request TLV
0x0039 mLACP Synchronization Data TLV
0x003A mLACP Disconnect Cause TLV
This document uses several new Status codes. IANA maintains the "Status Code Name Space" registry as defined by [RFC5036]. The following values have been assigned; the "E" column is the required setting of the Status Code E-bit.
本文档使用了几个新的状态代码。IANA维护[RFC5036]定义的“状态代码名称空间”注册表。已指定以下值：；“E”列是状态代码E位的必要设置。
Range/Value E Description
------------ ----- ------------------------------------------
0x00010001 0 Unknown ICCP RG
0x00010002 0 ICCP Connection Count Exceeded
0x00010003 0 ICCP Application Connection Count Exceeded
0x00010004 0 ICCP Application not in RG
0x00010005 0 Incompatible ICCP Protocol Version
0x00010006 0 ICCP Rejected Message
0x00010007 0 ICCP Administratively Disabled
0x00010010 0 ICCP RG Removed
0x00010011 0 ICCP Application Removed from RG
Range/Value E Description
------------ ----- ------------------------------------------
0x00010001 0 Unknown ICCP RG
0x00010002 0 ICCP Connection Count Exceeded
0x00010003 0 ICCP Application Connection Count Exceeded
0x00010004 0 ICCP Application not in RG
0x00010005 0 Incompatible ICCP Protocol Version
0x00010006 0 ICCP Rejected Message
0x00010007 0 ICCP Administratively Disabled
0x00010010 0 ICCP RG Removed
0x00010011 0 ICCP Application Removed from RG
The authors wish to acknowledge the important contributions of Dennis Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami Boutros, Neil Ketley, and Mark Christopher Sains.
作者希望感谢Dennis Cai、Neil McGill、Amir Maleki、Dan Biagini、Robert Leger、Sami Boutros、Neil Ketley和Mark Christopher Sains的重要贡献。
The authors also thank Daniel Cohn, Lizhong Jin, and Ran Chen for their valuable input, discussions, and comments.
作者还感谢Daniel Cohn、Lizhong Jin和Ran Chen的宝贵意见、讨论和评论。
[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月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and metropolitan area networks--Link Aggregation", IEEE Computer Society, November 2008.
[IEEE-802.1AX]IEEE标准802.1AX-2008，“局域网和城域网的IEEE标准——链路聚合”，IEEE计算机学会，2008年11月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire Preferential Forwarding Status Bit", RFC 6870, February 2013.
[RFC6870]Muley，P.，Ed.，和M.Aissaoui，Ed.，“伪线优先转发状态位”，RFC 68702013年2月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC2922] Bierman, A. and K. Jones, "Physical Topology MIB", RFC 2922, September 2000.
[RFC2922]Bierman，A.和K.Jones，“物理拓扑MIB”，RFC 2922，2000年9月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[LDP-CRYPTO] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, June 2014.
[LDP-CRYPTO]Zheng，L.，Chen，M.和M.Bhatia，“LDP Hello加密认证”，正在进行的工作，2014年6月。
Authors' Addresses
作者地址
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 United States EMail: lmartini@cisco.com
Luca Martini Cisco Systems，Inc.地址：美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室邮编：80112电子邮件：lmartini@cisco.com
Samer Salam Cisco Systems, Inc. 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada EMail: ssalam@cisco.com
Samer Salam Cisco Systems，Inc.加拿大不列颠哥伦比亚省温哥华市伯拉德街595号2123室V7X 1J1电子邮件：ssalam@cisco.com
Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States EMail: sajassi@cisco.com
Ali Sajassi Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134电子邮件：sajassi@cisco.com
Matthew Bocci Alcatel-Lucent Voyager Place Shoppenhangers Road Maidenhead Berks, SL6 2PJ UK EMail: matthew.bocci@alcatel-lucent.com
Matthew Bocci Alcatel-Lucent Voyager Place Shoppenigers Road Maidenhead Berks，SL6 2PJ英国电子邮件：Matthew。bocci@alcatel-朗讯网
Satoru Matsushima Softbank Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo 105-7304 Japan EMail: satoru.matsushima@g.softbank.co.jp
松岛佐藤软银电信1-9-1，日本东京弥敦区东新桥105-7304电子邮件：佐藤。matsushima@g.softbank.co.jp
Thomas Nadeau Brocade EMail: tnadeau@brocade.com
Thomas Nadeau Brocade电子邮件：tnadeau@brocade.com