Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 7727 H. Wen
Category: Standards Track Huawei
ISSN: 2070-1721 J. Hu
China Telecom
January 2016
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 7727 H. Wen
Category: Standards Track Huawei
ISSN: 2070-1721 J. Hu
China Telecom
January 2016
Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
生成树协议（STP）机箱间通信协议（ICCP）的应用
Abstract
摘要
The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.
机箱间通信协议（ICCP）支持机箱间冗余机制，该机制用于支持高网络可用性。
In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.
在本文档中，运行ICCP的冗余组（RG）中的提供商边缘（PE）设备用于提供到生成树协议（STP）网络的多宿连接，以提高STP网络的可用性。定义了ICCP TLV和ICCP STP应用程序的用途。
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/rfc7727.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7727.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Use Case ........................................................5
3. Spanning Tree Protocol Application TLVs .........................6
3.1. STP Connect TLV ............................................6
3.2. STP Disconnect TLV .........................................7
3.2.1. STP Disconnect Cause Sub-TLV ........................8
3.3. STP Configuration TLVs .....................................8
3.3.1. STP System Config ...................................9
3.3.2. STP Region Name ....................................10
3.3.3. STP Revision Level .................................10
3.3.4. STP Instance Priority ..............................11
3.3.5. STP Configuration Digest ...........................12
3.4. STP State TLVs ............................................12
3.4.1. STP Topology Changed Instances .....................12
3.4.2. STP CIST Root Time Parameters ......................14
3.4.3. STP MSTI Root Time Parameter .......................15
3.5. STP Synchronization Request TLV ...........................16
3.6. STP Synchronization Data TLV ..............................17
4. Operations .....................................................18
4.1. Common AC Procedures ......................................18
4.1.1. Remote PE Node Failure or Isolation ................19
4.1.2. Local PE Isolation .................................19
4.2. ICCP STP Application Procedures ...........................19
4.2.1. Initial Setup ......................................19
4.2.2. Configuration Synchronization ......................20
4.2.3. State Synchronization ..............................21
4.2.4. Failure and Recovery ...............................22
5. Security Considerations ........................................22
6. IANA Considerations ............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
Acknowledgements ................................................. 24
Authors' Addresses ............................................... 25
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Use Case ........................................................5
3. Spanning Tree Protocol Application TLVs .........................6
3.1. STP Connect TLV ............................................6
3.2. STP Disconnect TLV .........................................7
3.2.1. STP Disconnect Cause Sub-TLV ........................8
3.3. STP Configuration TLVs .....................................8
3.3.1. STP System Config ...................................9
3.3.2. STP Region Name ....................................10
3.3.3. STP Revision Level .................................10
3.3.4. STP Instance Priority ..............................11
3.3.5. STP Configuration Digest ...........................12
3.4. STP State TLVs ............................................12
3.4.1. STP Topology Changed Instances .....................12
3.4.2. STP CIST Root Time Parameters ......................14
3.4.3. STP MSTI Root Time Parameter .......................15
3.5. STP Synchronization Request TLV ...........................16
3.6. STP Synchronization Data TLV ..............................17
4. Operations .....................................................18
4.1. Common AC Procedures ......................................18
4.1.1. Remote PE Node Failure or Isolation ................19
4.1.2. Local PE Isolation .................................19
4.2. ICCP STP Application Procedures ...........................19
4.2.1. Initial Setup ......................................19
4.2.2. Configuration Synchronization ......................20
4.2.3. State Synchronization ..............................21
4.2.4. Failure and Recovery ...............................22
5. Security Considerations ........................................22
6. IANA Considerations ............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
Acknowledgements ................................................. 24
Authors' Addresses ............................................... 25
Inter-Chassis Communication Protocol (ICCP [RFC7275]) specifies a multi-chassis redundancy mechanism that enables Provider Edge (PE) devices located in a multi-chassis arrangement to act as a single Redundancy Group (RG).
机箱间通信协议（ICCP[RFC7275]）指定了一种多机箱冗余机制，使位于多机箱布置中的提供商边缘（PE）设备能够充当单个冗余组（RG）。
With the Spanning Tree Protocol (STP), a spanning tree will be formed over connected bridges by blocking some links between these bridges so that forwarding loops are avoided. This document introduces support of STP as a new application of ICCP. When a bridged STP network is connected to an RG, this STP application of ICCP enables the RG members to act as a single root bridge participating in the operations of STP.
在生成树协议（STP）中，通过阻塞这些网桥之间的一些链路，在连接的网桥上形成生成树，从而避免转发循环。本文档介绍了STP作为ICCP新应用程序的支持。当桥接STP网络连接到RG时，ICCP的STP应用程序使RG成员能够充当参与STP操作的单根网桥。
STP-relevant information needs to be exchanged and synchronized among the RG members. New ICCP TLVs for the ICCP STP application are specified for this purpose.
需要在RG成员之间交换和同步STP相关信息。为此，指定了用于ICCP STP应用的新ICCP TLV。
From the point of view of the customer, the Service Provider is providing a Virtual Private LAN Service (VPLS) [RFC4762].
从客户的角度来看，服务提供商正在提供虚拟专用LAN服务（VPLS）[RFC4762]。
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]中所述进行解释。
ICCP: Inter-Chassis Communication Protocol VPLS: Virtual Private LAN Service STP: Spanning Tree Protocol MSTP: Multiple Spanning Tree Protocol MST: Multiple Spanning Trees CIST: Common and Internal Spanning Tree ([802.1q], Section 3.27) MSTI: Multiple Spanning Tree Instance ([802.1q], Section 3.138) BPDU: Bridge Protocol Data Unit
ICCP:机箱间通信协议VPLS:虚拟专用LAN服务STP:生成树协议MSTP:多生成树协议MST:多生成树CIST:公共和内部生成树（[802.1q]，第3.27节）MSTI:多生成树实例（[802.1q]，第3.138节）BPDU:网桥协议数据单元
In this document, unless otherwise explicitly noted, the term "STP" also covers MSTP.
在本文件中，除非另有明确说明，否则术语“STP”也包括MSTP。
Customers widely use Ethernet as an access technology [RFC4762]. It's common that one customer's Local Area Network (LAN) has multiple bridges connected to a carrier's network at different locations for reliability purposes. Requirements for this use case are listed as follows.
客户广泛使用以太网作为接入技术[RFC4762]。一个客户的局域网（LAN）通常有多个网桥连接到不同位置的运营商网络，以提高可靠性。该用例的要求如下所示。
o Customers desire to balance the load among their available connections to the carrier's network; therefore, all the connections need to be active.
o 客户希望在其与运营商网络的可用连接之间平衡负载；因此，所有连接都需要处于活动状态。
o When one connection to the carrier network fails, customers require a connection in another location to continue to work after the reconvergence of the STP rather than compromising the whole STP network. The failure of the connection may be due to the failure of the PE, the attachment circuit (AC), or even the Customer Edge (CE) device itself.
o 当一个与运营商网络的连接出现故障时，客户需要另一个位置的连接，以便在STP重新聚合后继续工作，而不是危及整个STP网络。连接故障可能是由于PE、连接电路（AC）甚至客户边缘（CE）设备本身的故障造成的。
In order to meet these requirements, the 'ICCP-STP' model is proposed. It introduces STP as a new application of ICCP.
为了满足这些要求，提出了“ICCP-STP”模型。介绍了STP作为ICCP的一个新应用。
+--------------+ +=============+
| | | |
| | | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE1+<6>-------<5>+ PE1 || | |
| <1> +---+ | | +-----+|<--|--Pseudowire-->|
| +-+-+ | | || |
| |CE3| | | ||ICCP |--> Towards the Core
| +-+-+ | | || |
| <2> +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE2+<3>-------<4>+ PE2 || | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| | | |
| Multihomed | | Redundancy |
| STP Network | | Group |
+--------------+ +=============+
+--------------+ +=============+
| | | |
| | | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE1+<6>-------<5>+ PE1 || | |
| <1> +---+ | | +-----+|<--|--Pseudowire-->|
| +-+-+ | | || |
| |CE3| | | ||ICCP |--> Towards the Core
| +-+-+ | | || |
| <2> +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE2+<3>-------<4>+ PE2 || | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| | | |
| Multihomed | | Redundancy |
| STP Network | | Group |
+--------------+ +=============+
Figure 1: A STP network is multihomed to an RG running ICCP
图1:STP网络多宿于运行ICCP的RG
Figure 1 shows an example topology of this model. With ICCP, the whole RG will be virtualized to be a single bridge. Each RG member has its BridgeIdentifier (the MAC address). The numerically lowest one is used as the BridgeIdentifier of the 'virtualized root bridge'. The RG acts as if the ports connected to the STP network (ports <4> and <5>) are for the same root bridge. All these ports send the configuration BPDU with the highest root priority to trigger the
图1显示了该模型的一个示例拓扑。通过ICCP，整个RG将虚拟化为一个网桥。每个RG成员都有其BridgeIdentifier（MAC地址）。数字最低的一个用作“虚拟化根网桥”的网桥标识符。RG的作用就像连接到STP网络的端口（端口<4>和<5>）用于同一根网桥。所有这些端口发送具有最高根优先级的配置BPDU以触发
construction of the spanning tree. The link between the peering PEs is not visible to the bridge domains of the STP network. In this way, the STP will always break a possible loop within the multihomed STP network by breaking the whole network into separate islands so that each is attached to one PE. That forces all PEs in the RG to be active. This is different from a generic VPLS [RFC4762] where the root bridge resides in the customer network and the multihomed PEs act in the active-standby mode. Note that the specification of VPLS remains unchanged other than for this operation. For instance, a full-mesh of pseudowires (PWs) is established between PEs, and the "split horizon" rule is still used to perform the loop-breaking through the core.
生成树的构造。对等PE之间的链路对STP网络的网桥域不可见。通过这种方式，STP将始终通过将整个网络拆分为单独的孤岛来中断多宿STP网络中的可能环路，以便每个孤岛都连接到一个PE。这将强制RG中的所有PE处于活动状态。这与普通VPLS[RFC4762]不同，后者根网桥位于客户网络中，多宿PEs在主备模式下工作。请注意，除此操作外，VPLS的规格保持不变。例如，在PEs之间建立一个完整的伪线网格（PWs），并且仍然使用“分割地平线”规则来执行穿过核心的环路中断。
This section specifies the ICCP TLVs for the ICCP STP application. The Unknown TLV bit (U-bit) and the Forward unknown TLV bit (F-bit) of the following TLVs MUST be sent as cleared and processed on receipt as specified in [RFC7275].
本节规定了ICCP STP应用程序的ICCP TLV。以下TLV的未知TLV位（U位）和前向未知TLV位（F位）必须按照[RFC7275]中的规定在接收时以清除和处理的方式发送。
This TLV is included in the RG Connect Message to signal the initiation of an ICCP STP application connection.
该TLV包含在RG Connect消息中，以发出ICCP STP应用程序连接启动的信号。
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=0x2000 | 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=0x2000 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2000 for "STP Connect TLV"
“STP连接TLV”设置为0x2000
- 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 ICCP STP application protocol. This document defines version 0x0001.
ICCP STP应用协议的版本。本文档定义了版本0x0001。
- A bit
- 一点
Acknowledgement Bit. Set to 1 if the sender has received a STP Connect TLV from the recipient. Otherwise, set to 0.
确认位。如果发送方从接收方接收到STP Connect TLV，则设置为1。否则，设置为0。
- Reserved
- 含蓄的
Reserved for future use. These bits MUST be sent as 0 and ignored on receipt.
保留供将来使用。这些位必须作为0发送，并在收到时忽略。
- Optional Sub-TLVs
- 可选子TLV
There are no optional Sub-TLVs defined for this version of the protocol.
没有为此版本的协议定义可选的子TLV。
This TLV is used in the RG Disconnect Message to indicate that the connection for the ICCP STP application is to be terminated.
该TLV用于RG Disconnect消息，以指示ICCP STP应用程序的连接将被终止。
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=0x2001 | 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=0x2001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2001 for "STP Disconnect TLV"
将“STP断开TLV”设置为0x2001
- 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 "STP Disconnect Cause" sub-TLV, defined below:
为本版本协议定义的唯一可选子TLV是“STP断开原因”子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=0x200C | 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=0x200C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x200C for "STP Disconnect Cause TLV"
将“STP断开原因TLV”设置为0x200C
- 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 [RFC3629] format. Used for operational purposes.
指定断开原因的可变长度字符串，以UTF-8[RFC3629]格式编码。用于操作目的。
The STP Configuration TLVs are sent in the RG Application Data Message. When an STP Config TLV is received by a peer RG member, the member MUST synchronize with the configuration information contained in the TLV. TLVs specified in Sections 3.3.1 to 3.3.5 define specific configuration information.
STP配置TLV在RG应用程序数据消息中发送。当对等RG成员接收到STP Config TLV时，该成员必须与TLV中包含的配置信息同步。第3.3.1节至第3.3.5节中规定的TLV定义了特定的配置信息。
This TLV announces the local node's STP System Parameters to the RG peers.
该TLV向RG对等方宣布本地节点的STP系统参数。
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=0x2002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x2002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2002 for "STP System Config TLV"
“STP系统配置TLV”设置为0x2002
- Length
- 长
Length of the ROID plus the MAC address in octets. Always set to 14.
ROID的长度加上MAC地址（以八位字节为单位）。始终设置为14。
- ROID
- ROID
Redundant Object Identifier; format defined in Section 6.1.3 of [RFC7275].
冗余对象标识符；[RFC7275]第6.1.3节中定义的格式。
- MAC Address
- MAC地址
The MAC address of the sender. This MAC address is set to the BridgeIdentifier of the sender, as defined in [802.1q], Section 13.26.2. The numerically lowest 48-bit unsigned value of BridgeIdentifier is used as the MAC address of the Virtual Root Bridge mentioned in Section 2.
发件人的MAC地址。根据[802.1q]第13.26.2节的定义，该MAC地址设置为发送方的桥接标识符。BridgeIdentifier的数字最低的48位无符号值用作第2节中提到的虚拟根网桥的MAC地址。
This TLV carries the value of Region Name.
此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=0x2003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region 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=0x2003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2003 for "STP Region Name TLV"
“STP区域名称TLV”设置为0x2003
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。
- Region Name
- 地区名称
The Name of the MST Region as specified in [802.1q], Section 3.142.
[802.1q]第3.142节中规定的MST区域名称。
This TLV carries the value of Revision Level.
此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=0x2004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revision Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x2004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revision Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2004 for "STP Revision Level TLV".
“STP修订级别TLV”设置为0x2004。
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 2.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。始终设置为2。
- Revision Level
- 修订级别
The Revision Level as specified in [802.1q], Section 13.8, item c.
[802.1q]第13.8节第c项中规定的修订级别。
This TLV carries the value of Instance Priority to other members in the 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=0x2005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x2005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2005 for "STP Instance Priority TLV"
“STP实例优先级TLV”设置为0x2005
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。
- Pri
- 脉波重复间隔
The Instance Priority. It is interpreted as unsigned integer with higher value indicating a higher priority.
实例优先级。它被解释为无符号整数，值越大表示优先级越高。
- InstanceID
- 实例ID
The 12-bit Instance Identifier of the CIST or MSTI. This parameter takes a value in the range 1 through 4094 for MSTI (as defined in [802.1q], Section 12.8.1.2.2) and takes value of 0 for CIST.
CIST或MSTI的12位实例标识符。对于MSTI（定义见[802.1q]第12.8.1.2.2节），该参数的取值范围为1到4094，对于CIST，该参数的取值范围为0。
This TLV carries the value of STP VLAN Instance Mapping.
此TLV携带STP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Configuration Digest |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x2006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Configuration Digest |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2006 for "STP Configuration Digest TLV"
“STP配置摘要TLV”设置为0x2006
- Length
- 长
Length of the STP Configuration Digest in octets. Always set to 16.
STP配置摘要的长度（以八位字节为单位）。始终设置为16。
- Configuration Digest
- 配置摘要
As specified in [802.1q], Section 13.8, item d.
按照[802.1q]第13.8节第d项的规定。
The STP State TLVs are sent in the RG Application Data Message. They are used by a PE device to report its STP status to other members in the RG. Such TLVs are specified in the following subsections.
STP状态TLV在RG应用程序数据消息中发送。PE设备使用它们向RG中的其他成员报告其STP状态。以下小节中规定了此类TLV。
This TLV is used to report the Topology Changed Instances to other members of the RG. The sender monitors Topology Change Notification (TCN) messages and generates this list. The receiving RG member MUST initiate the Topology Change event, including sending BPDU with the Topology Change flag set to 1 out of the designated port(s) of the Topology Changed bridge domains of the STP network, and flushing out MAC addresses relevant to the instances listed in this TLV.
此TLV用于向RG的其他成员报告拓扑更改的实例。发送方监视拓扑更改通知（TCN）消息并生成此列表。接收RG成员必须启动拓扑更改事件，包括发送BPDU，将拓扑更改标志设置为STP网络拓扑更改网桥域的指定端口中的1个，并清除与此TLV中列出的实例相关的MAC地址。
If the PE device supports MAC Address Withdrawal (see Section 6.2 of [RFC4762]), it SHOULD send a Label Distribution Protocol (LDP) Address Withdraw Message with the list of MAC addresses towards the core over the corresponding LDP sessions. It is not necessary to
如果PE设备支持MAC地址撤回（参见[RFC4762]第6.2节），则应通过相应的LDP会话向核心发送标签分发协议（LDP）地址撤回消息，其中包含MAC地址列表。没有必要
send such a message to PEs of the same RG since the flushing of their MAC address tables should have been performed upon receipt of the STP Topology Changed Instances TLV.
向同一RG的PEs发送此类消息，因为在收到STP拓扑更改实例TLV后，应已对其MAC地址表进行刷新。
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=0x2007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x2007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2007 for "STP Topology Changed Instances TLV"
将“STP拓扑更改实例TLV”设置为0x2007
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。
- InstanceID List
- 实例ID列表
The list of the InstanceIDs of the CIST or MSTIs whose topologies have changed as indicated by the TCN messages as specified in [802.1q], Section 13.14. The list is formatted by padding each InstanceID value to the 16-bit boundary as follows, where the bits in the "R" fields MUST be sent as 0 and ignored on receipt.
根据[802.1q]第13.14节中规定的TCN消息，拓扑已发生变化的CIST或MSTI实例ID列表。列表的格式是将每个InstanceID值填充到16位边界，如下所示，“R”字段中的位必须作为0发送，并在接收时忽略。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R| InstanceID#1 |R|R|R|R| InstanceID#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R| InstanceID#1 |R|R|R|R| InstanceID#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to report the Value of CIST Root Time Parameters ([802.1q], Section 13.26.7) to other members of the RG. All time parameter values are in seconds with a granularity of 1. For ranges and default values of these parameter values, refer to [802.1d1998], Section 8.10.2, Table 8-3; [802.1d2004] Section 17.14, Table 17-1; and [802.1q], Section 13.26.7.
该TLV用于向RG的其他成员报告CIST根时间参数的值（[802.1q]，第13.26.7节）。所有时间参数值均以秒为单位，粒度为1。有关这些参数值的范围和默认值，请参考[802.1d1998]，第8.10.2节，表8-3；[802.1d2004]第17.14节，表17-1；和[802.1q]，第13.26.7节。
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=0x2008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxAge | MessageAge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdDelay | HelloTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RemainingHops |
+-+-+-+-+-+-+-+-+
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=0x2008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxAge | MessageAge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdDelay | HelloTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RemainingHops |
+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2008 for "STP CIST Root Time TLV"
“STP CIST根时间TLV”设置为0x2008
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 9.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。始终设置为9。
- MaxAge
- MaxAge
The Max Age of the CIST. It is the maximum age of the information transmitted by the bridge when it is the Root Bridge ([802.1d2004], Section 17.13.8).
CIST的最大年龄。当网桥是根网桥时，它是网桥传输信息的最长年限（[802.1d2004]，第17.13.8节）。
- MessageAge
- 信息时代
The Message Age of the CIST (see [802.1q], Section 13.26.7).
CIST的信息时代（见[802.1q]，第13.26.7节）。
- FwdDelay
- 快走
The Forward Delay of the CIST. It is the delay used by STP Bridges to transition Root and Designated Ports to Forwarding ([802.1d2004], Section 17.13.5).
CIST的前向延迟。它是STP网桥用于将根端口和指定端口转换为转发的延迟（[802.1d2004]，第17.13.5节）。
- HelloTime
- HelloTime
The Hello Time of the CIST. It is the interval between periodic transmissions of Configuration Messages by Designated Ports ([802.1d2004], Section 17.13.6).
CIST的问候时间。它是指定端口定期传输配置消息之间的间隔（[802.1d2004]，第17.13.6节）。
- RemainingHops
- 剩余啤酒花
The remainingHops of the CIST ([802.1q], Section 13.26.7).
CIST的剩余部分（[802.1q]，第13.26.7节）。
This TLV is used to report the parameter value of MSTI Root Time to other members of the RG. As defined in [802.1q], Section 13.26.7, it is the value of remainingHops for the given MSTI.
此TLV用于向RG的其他成员报告MSTI根时间的参数值。如[802.1q]第13.26.7节所定义，它是给定MSTI的剩余跳数值。
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=0x2009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID | RemainingHops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x2009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID | RemainingHops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x2009 for "STP MSTI Root Time TLV"
“STP MSTI根时间TLV”设置为0x2009
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 3.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。始终设置为3。
- Pri
- 脉波重复间隔
The Instance Priority. It is interpreted as an unsigned integer with higher value indicating a higher priority.
实例优先级。它被解释为一个无符号整数，值越大表示优先级越高。
- InstanceID
- 实例ID
The 12-bit Instance Identifier of the Multiple Spanning Tree Instance (MSTID). As defined in [802.1q], Section 12.8.1.2.2, this parameter takes a value in the range 1 through 4094.
多生成树实例（MSTID）的12位实例标识符。如[802.1q]第12.8.1.2.2节所定义，该参数取值范围为1到4094。
- RemainingHops
- 剩余啤酒花
The remainingHops of the MSTI. It is encoded in the same way as in [802.1q], Section 14.4.1, item f.
MSTI的剩余部分。其编码方式与[802.1q]第14.4.1节第f项中的编码方式相同。
The STP 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应用程序数据消息中使用STP同步请求TLV。设备使用此TLV请求其对等方重新传输配置或操作状态。可要求提供以下信息：
- configuration and/or state of the STP system, - configuration and/or state for a given list of instances.
- STP系统的配置和/或状态-给定实例列表的配置和/或状态。
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=0x200A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=0x200A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
Set to 0x200A for "STP Synchronization Request TLV"
“STP同步请求TLV”设置为0x200A
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 4.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。始终设置为4。
- Request Number
- 请求号码
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a corresponding response. The value of 0 is reserved for unsolicited synchronization, and it MUST NOT be used in the STP Synchronization Request TLV. As indicated in [RFC7275], given the use of TCP, there are no issues associated with the wrap-around of the Request Number.
2个八位组。唯一标识请求的无符号整数。用于将请求与相应的响应匹配。0的值保留用于未经请求的同步，并且不得在STP同步请求TLV中使用。如[RFC7275]所示，由于使用了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 System Data 0x01 Request data of the listed instances 0x3FFF Request System Data and data of all instances
0x00请求系统数据0x01所列实例的请求数据0x3FFF请求系统数据和所有实例的数据
- InstanceID List
- 实例ID列表
The InstanceIDs of the CIST or MSTIs; format specified in Section 3.4.1.
CIST或MSTIs的实例ID；第3.4.1节规定的格式。
The pair of STP Synchronization Data TLVs are used by the sender to delimit a set of TLVs that are being transmitted in response to an STP Synchronization Request TLV. The delimiting TLVs signal the start and end of the synchronization data, and they associate the response with its corresponding request via the Request Number field. It's REQUIRED that each pair of STP Synchronization Data TLVs occur in the same fragment. When the total size of the TLVs to be transmitted exceeds the maximal size of a fragment, these TLVs MUST be divided into multiple sets, delimited by multiple pairs of STP Synchronization Data TLVs, and filled into multiple fragments. With the Request Number, lost fragments can be identified and re-requested.
发送方使用这对STP同步数据TLV来限定响应STP同步请求TLV而传输的一组TLV。定界TLV向同步数据的开始和结束发送信号，并通过请求编号字段将响应与其相应的请求相关联。要求每对STP同步数据TLV出现在同一个片段中。当要传输的TLV的总大小超过片段的最大大小时，必须将这些TLV划分为多个集合，由多对STP同步数据TLV分隔，并填充到多个片段中。通过请求编号，可以识别丢失的片段并重新请求。
The STP Synchronization Data TLVs are also used for unsolicited advertisements of complete STP configuration and operational state data. The Request Number field MUST be set to 0 in this case.
STP同步数据TLV还用于完整STP配置和运行状态数据的非请求发布。在这种情况下，请求编号字段必须设置为0。
STP Synchronization Data TLV has the following format:
STP同步数据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=0x200B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Reserved |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=0x200B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U=F=0
- Type
- 类型
set to 0x200B for "STP Synchronization Data TLV"
“STP同步数据TLV”设置为0x200B
- Length
- 长
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 4.
TLV的长度（以八位字节为单位），不包括U位、F位、类型和长度字段。始终设置为4。
- Request Number
- 请求号码
2 octets. Unsigned integer identifying the Request Number of the "STP Synchronization Request TLV" that initiated this synchronization data response.
2个八位组。无符号整数，标识发起此同步数据响应的“STP同步请求TLV”的请求号。
- Reserved
- 含蓄的
Reserved bits for future use. These MUST be sent as 0 and ignored on receipt.
保留位供将来使用。这些必须作为0发送，并在收到时忽略。
- S
- s
S = 0: Synchronization Data Start
S = 1: Synchronization Data End
S = 0: Synchronization Data Start
S = 1: Synchronization Data End
Operational procedures for AC redundancy applications have been specified in Section 9.2 of [RFC7275]. The operational procedures of the ICCP STP application should follow those procedures, with the changes presented in this section.
[RFC7275]第9.2节规定了交流冗余应用的操作程序。ICCP STP应用程序的操作程序应遵循这些程序，并在本节中介绍更改。
The following changes are introduced to the generic procedures of AC redundancy applications defined in Section 9.2.1 of [RFC7275].
[RFC7275]第9.2.1节中定义的交流冗余应用的通用程序引入了以下更改。
When a local PE device detects that a remote PE device that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5 of [RFC7275]), the local PE device checks if it has redundancy ACs for the affected services. If redundant ACs are present, and if the local PE device has the new highest bridge priority, the local PE device becomes the virtual root bridge for corresponding ACs.
当本地PE设备检测到作为同一RG成员的远程PE设备不再可访问（使用[RFC7275]第5节中描述的机制）时，本地PE设备检查其是否具有受影响服务的冗余ACs。如果存在冗余ACs，并且本地PE设备具有新的最高网桥优先级，则本地PE设备将成为相应ACs的虚拟根网桥。
When a PE device detects that it has been isolated from the core network, then it needs to ensure that its AC redundancy mechanism will change the status of all active ACs to standby. The AC redundancy application SHOULD then send an RG Application Data Message in order to trigger failover to another active PE device in the RG. Note that this works only in the case of dedicated interconnect (Sections 3.2.1 and 3.2.3), since ICCP will still have the path to the peer, even though the PE device is isolated from the MPLS core network.
当PE设备检测到它已与核心网络隔离时，它需要确保其AC冗余机制将所有活动AC的状态更改为备用。然后，AC冗余应用程序应发送RG应用程序数据消息，以触发到RG中另一个活动PE设备的故障切换。请注意，这仅适用于专用互连（第3.2.1节和第3.2.3节），因为即使PE设备与MPLS核心网络隔离，ICCP仍将具有到对等方的路径。
This section defines the procedures of the ICCP STP application that are applicable for Ethernet ACs.
本节定义了适用于以太网ACs的ICCP STP应用程序的程序。
When an RG is configured on a system that supports the ICCP STP application, such systems MUST send an RG Connect Message with an STP Connect TLV to each PE device that is a member of the RG. The sending PE device MUST set the A bit to 1 in that TLV if it has received a corresponding STP Connect TLV from its peer PE; otherwise, the sending PE device MUST set the A bit to 0. If a PE device receives an STP Connect TLV from its peer after sending its own TLV with the A bit set to 0, it MUST resend the TLV with the A bit set to 1. A system considers the ICCP STP application connection to be operational when it has both sent and received STP Connect TLVs with the A bit set to 1. When the ICCP STP application connection between a pair of PEs is operational, the two devices can start exchanging RG Application Data Messages for the ICCP STP application. This involves having each PE device advertise its STP configuration and operational state in an unsolicited manner. A PE device SHOULD follow the order below when advertising its STP state upon initial application connection setup:
在支持ICCP STP应用程序的系统上配置RG时，此类系统必须向作为RG成员的每个PE设备发送带有STP Connect TLV的RG Connect消息。如果发送PE设备已从其对等PE接收到相应的STP Connect TLV，则必须将该TLV中的A位设置为1；否则，发送PE设备必须将A位设置为0。若PE设备在发送其自己的TLV（位设置为0）后从其对等方接收到STP Connect TLV，它必须重新发送位设置为1的TLV。当系统发送和接收位设置为1的STP Connect TLV时，系统认为ICCP STP应用程序连接可操作。当一对PE之间的ICCP STP应用程序连接运行时，两个设备可以开始为ICCP STP应用程序交换RG应用程序数据消息。这涉及到让每个PE设备以未经请求的方式公布其STP配置和操作状态。在初始应用程序连接设置时，PE设备在公布其STP状态时应遵循以下顺序：
- Advertise the STP System Config TLV - Advertise remaining Configuration TLVs - Advertise State TLVs
- 播发STP系统配置TLV-播发剩余配置TLV-播发状态TLV
The update of the information contained in the State TLVs depends on that in the Configuration TLVs. By sending the TLVs in the above order, the two peers may begin to update STP state as early as possible in the middle of exchanging these TLVs.
状态TLV中包含的信息的更新取决于配置TLV中的信息。通过按上述顺序发送TLV，两个对等点可以在交换这些TLV的中间尽早开始更新STP状态。
A PE device MUST use a pair of STP Synchronization Data TLVs to delimit the entire set of TLVs that are being sent as part of this unsolicited advertisement.
PE设备必须使用一对STP同步数据TLV来限定作为此未经请求的广告的一部分发送的整个TLV集。
If a system receives an RG Connect Message with an STP Connect TLV that has a differing Protocol Version, it MUST follow the procedures outlined in the Section 4.4.1 ("Application Versioning") of [RFC7275].
如果系统接收到带有不同协议版本的STP Connect TLV的RG Connect消息，则必须遵循[RFC7275]第4.4.1节（“应用程序版本控制”）中概述的程序。
After the ICCP STP application connection has been established, every PE device MUST communicate its system-level configuration to its peers via the use of STP System Config TLV.
ICCP STP应用程序连接建立后，每个PE设备必须通过使用STP system Config TLV将其系统级配置与对等设备进行通信。
When the ICCP STP application is administratively disabled on the PE, or on the particular RG, the system MUST send an RG Disconnect Message containing STP Disconnect TLV.
当在PE或特定RG上以管理方式禁用ICCP STP应用程序时，系统必须发送包含STP DISCONTACT TLV的RG DISCONTACT消息。
A system that supports ICCP STP application MUST synchronize the configuration with other RG members. This is achieved via the use of STP Configuration TLVs. The PEs in the RG MUST all agree on the common MAC address to be associated with the virtual root bridge. It is possible to achieve this via consistent configuration on member PEs. However, in order to protect against possible misconfigurations, a virtual root bridge identifier MUST be set to the MAC address advertised by the PE device with the numerically lowest BridgeIdentifier (i.e., the MAC address of the bridge) in the RG.
支持ICCP STP应用程序的系统必须与其他RG成员同步配置。这是通过使用STP配置TLV实现的。RG中的PE必须一致同意与虚拟根网桥关联的公共MAC地址。通过成员PE上的一致配置，可以实现这一点。然而，为了防止可能的错误配置，必须将虚拟根网桥标识符设置为在RG中具有数字上最低的网桥标识符（即网桥的MAC地址）的PE设备所通告的MAC地址。
Furthermore, for a given ICCP STP application, an implementation MUST advertise the configuration prior to advertising its corresponding state. If a PE device receives any STP State TLV that it had not learned of before via an appropriate STP Configuration TLV, then the PE device MUST request synchronization of the configuration and state from its peer. If during such synchronization a PE device receives a State TLV that it has not learned before, then the PE device MUST send a NAK TLV for that particular TLV. The PE device MUST NOT request resynchronization in this case.
此外，对于给定的ICCP STP应用程序，实现必须在公布其相应状态之前公布配置。如果PE设备通过适当的STP配置TLV接收到其之前未获悉的任何STP状态TLV，则PE设备必须从其对等方请求配置和状态的同步。如果在这种同步过程中，PE设备接收到它以前未读入的状态TLV，则PE设备必须为该特定TLV发送NAK TLV。在这种情况下，PE设备不得请求重新同步。
PEs within the RG need to synchronize their state for proper STP operation. This is achieved by having each system advertise its running state in STP State TLVs. Whenever any STP parameter either on the CE or PE side is changed, the system MUST transmit an updated TLV for the affected STP instances. Moreover, when the administrative or operational state changes, the system MUST transmit an updated State TLV to its peers.
RG内的PE需要同步其状态，以确保STP正常运行。这是通过让每个系统在STP状态TLV中公布其运行状态来实现的。无论何时更改CE或PE侧的任何STP参数，系统都必须为受影响的STP实例发送更新的TLV。此外，当管理或操作状态发生变化时，系统必须向其对等方发送更新状态TLV。
A PE device MAY request its peer to retransmit previously advertised state. This is useful in case the PE device is recovering from a soft failure and attempting to relearn state. To request such retransmissions, a PE device MUST send a set of one or more STP Synchronization Request TLVs.
PE设备可请求其对等方重新传输先前公布的状态。这在PE设备从软故障中恢复并尝试重新学习状态时非常有用。要请求此类重传，PE设备必须发送一组一个或多个STP同步请求TLV。
A PE device MUST respond to a STP Synchronization Request TLV by sending the requested data in a set of one or more STP Configuration or State TLVs delimited by a pair of STP Synchronization Data TLVs.
PE设备必须通过发送由一对STP同步数据TLV分隔的一组或多个STP配置或状态TLV中的请求数据来响应STP同步请求TLV。
Note that the response may span across 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 RG Application Data Messages.
注意，响应可能跨越多个RG应用程序数据消息，例如，当超过MTU限制时；但是，必须在消息之间保留上述顺序，并且只有一对同步数据TLV必须用于在所有RG应用程序数据消息之间限定响应。
A PE device MAY readvertise its STP state in an unsolicited manner. This is done by sending the appropriate State TLVs delimited by a pair of STP Synchronization Data TLVs and using a Request Number of 0.
PE设备可以主动读取其STP状态。这是通过发送由一对STP同步数据TLV分隔的适当状态TLV并使用请求号0来完成的。
While a PE device has sent out a synchronization request for a particular PE device, it SHOULD silently ignore all TLVs that are from that node, are received prior to the synchronization response, and 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 should continue to be processed normally.
当PE设备已发送特定PE设备的同步请求时，它应默默地忽略来自该节点、在同步响应之前接收到的所有TLV，并携带所请求的相同类型的信息。这将使系统免于更新最终将被同步响应覆盖的状态的负担。请注意，与其他系统相关的TLV应继续正常处理。
If a PE device receives a synchronization request for an instance that doesn't exist or is not known to the PE, then it MUST trigger the unsolicited synchronization of all information by restarting the initialization.
如果PE设备接收到PE不存在或不知道的实例的同步请求，则必须通过重新启动初始化来触发所有信息的未经请求的同步。
If during the synchronization operation a PE device receives an advertisement of a Node ID value that is different from the value previously advertised, then the PE device MUST purge all state data previously received from that peer prior to the last synchronization.
如果在同步操作期间，PE设备接收到与先前公布的值不同的节点ID值的公布，则PE设备必须清除上次同步之前先前从该对等方接收到的所有状态数据。
When a PE device that is active for the ICCP STP application encounters a core isolation fault [RFC7275], it SHOULD attempt to fail over to a peer PE device that hosts the same RG. The default failover procedure is to have the failed PE device bring down the link(s) towards the multihomed STP network. This will cause the STP network to reconverge and to use the other links that are connected to the other PE devices in the RG. Other procedures for triggering failover are possible and are outside the scope of this document.
当ICCP STP应用程序的活动PE设备遇到核心隔离故障[RFC7275]时，应尝试故障转移到承载相同RG的对等PE设备。默认故障切换过程是让发生故障的PE设备断开通向多宿STP网络的链路。这将导致STP网络重新聚合，并使用连接到RG中其他PE设备的其他链路。触发故障转移的其他过程是可能的，不在本文档的范围之内。
If the isolated PE device is the one that has the numerically lowest BridgeIdentifier, PEs in the RG MUST synchronize STP Configuration and State TLVs and determine a new virtual root bridge as specified in Section 4.2.2.
如果隔离的PE设备具有数字上最低的桥接标识符，则RG中的PE必须同步STP配置和状态TLV，并根据第4.2.2节的规定确定新的虚拟根网桥。
Upon recovery from a previous fault, a PE device SHOULD NOT reclaim the role of the virtual root for the STP network even if it has the numerically lowest BridgeIdentifier among the RG. This minimizes traffic disruption.
从以前的故障恢复后，PE设备不应恢复STP网络的虚拟根的角色，即使其在RG中具有数字最低的桥接标识符。这样可以最大限度地减少交通中断。
Whenever the virtual root bridge changes, the STP Topology Changed Instances TLV lists the instances that are affected by the change. These instances MUST undergo a STP reconvergence procedure when this TLV is received as defined in Section 3.4.1.
每当虚拟根网桥发生更改时，STP拓扑更改实例TLV将列出受更改影响的实例。当按照第3.4.1节的规定收到该TLV时，这些实例必须经历STP重新聚合程序。
This document specifies an application running on the channel provided by ICCP [RFC7275]. The security considerations on ICCP apply in this document as well.
本文档指定了在ICCP[RFC7275]提供的通道上运行的应用程序。ICCP的安全注意事项也适用于本文件。
For the ICCP STP application, an attack on a channel (running in the provider's network) can break not only the ability to deliver traffic across the provider's network, but also the ability to route traffic within the customer's network. That is, a careful attack on a channel (such as the DoS attacks as described in [RFC7275]) can break STP within the customer network. Implementations need to provide mechanisms to mitigate these types of attacks. For example, the port between the PE device and the malicious CE device may be blocked.
对于ICCP STP应用程序，对通道（在提供商网络中运行）的攻击不仅会破坏通过提供商网络传输流量的能力，还会破坏在客户网络中路由流量的能力。也就是说，对通道的小心攻击（如[RFC7275]中所述的DoS攻击）会破坏客户网络中的STP。实现需要提供缓解这些类型攻击的机制。例如，PE设备和恶意CE设备之间的端口可能被阻止。
The IANA maintains a top-level registry called "Pseudowire Name Spaces (PWE3)". It has a subregistry called "ICC RG Parameter Types".
IANA维护一个名为“伪线名称空间（PWE3）”的顶级注册表。它有一个称为“ICC RG参数类型”的子区域。
IANA has made 13 allocations from this registry as shown below. IANA has allocated the codepoints from the range marked for assignment by IETF Review (0x2000-0x2FFF) [RFC5226]. Each assignment references this document.
IANA已从该注册中心进行了13次分配，如下所示。IANA已从IETF Review（0x2000-0x2FF）[RFC5226]标记的分配范围内分配了代码点。每份作业均参考本文件。
Parameter Type Description
-------------- ---------------------------------
0x2000 STP Connect TLV
0x2001 STP Disconnect TLV
0x2002 STP System Config TLV
0x2003 STP Region Name TLV
0x2004 STP Revision Level TLV
0x2005 STP Instance Priority TLV
0x2006 STP Configuration Digest TLV
0x2007 STP Topology Changed Instances TLV
0x2008 STP CIST Root Time TLV
0x2009 STP MSTI Root Time TLV
0x200A STP Synchronization Request TLV
0x200B STP Synchronization Data TLV
0x200C STP Disconnect Cause TLV
Parameter Type Description
-------------- ---------------------------------
0x2000 STP Connect TLV
0x2001 STP Disconnect TLV
0x2002 STP System Config TLV
0x2003 STP Region Name TLV
0x2004 STP Revision Level TLV
0x2005 STP Instance Priority TLV
0x2006 STP Configuration Digest TLV
0x2007 STP Topology Changed Instances TLV
0x2008 STP CIST Root Time TLV
0x2009 STP MSTI Root Time TLV
0x200A STP Synchronization Request TLV
0x200B STP Synchronization Data TLV
0x200C STP Disconnect Cause TLV
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, DOI 10.17487/RFC7275, June 2014, <http://www.rfc-editor.org/info/rfc7275>.
[RFC7275]Martini，L.，Salam，S.，Sajassi，A.，Bocci，M.，Matsushima，S.，和T.Nadeau，“第2层虚拟专用网络（L2VPN）提供商边缘（PE）冗余的机箱间通信协议”，RFC 7275，DOI 10.17487/RFC72752014年6月<http://www.rfc-editor.org/info/rfc7275>.
[802.1q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014.
[802.1q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准802.1q-2014，DOI 10.1109/IEEESTD.2014.6991462，2014。
[802.1d1998] IEEE, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specifications -- Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D-1998, DOI 10.1109/IEEESTD.1998.95619, 1998.
[802.1d1998]IEEE，“信息技术——系统间电信和信息交换——局域网和城域网——通用规范——第3部分：媒体访问控制（MAC）网桥”，ANSI/IEEE标准802.1D-1998，DOI 10.1109/IEEESTD.1998.95619，1998。
[802.1d2004] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges", IEEE Std 802.1D-2004, DOI 10.1109/ieeestd.2004.94569, 2004.
[802.1d2004]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）网桥”，IEEE标准802.1D-2004，DOI 10.1109/ieeestd.2004.945692004。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
Acknowledgements
致谢
The authors would like to thank the comments and suggestions from Ignas Bagdonas, Adrian Farrel, Andrew G. Malis, Gregory Mirsky, and Alexander Vainshtein.
作者要感谢伊格纳斯·巴格多纳斯、阿德里安·法雷尔、安德鲁·G·马里、格雷戈里·米尔斯基和亚历山大·范斯坦的评论和建议。
Authors' Addresses
作者地址
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Huafeng Wen Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号华丰文华威科技210012
Email: wenhuafeng@huawei.com
Email: wenhuafeng@huawei.com
Jie Hu China Telecom Beijing Information Science & Technology Innovation Park Beiqijia Town Changping District, Beijing 102209 China
中国电信北京信息科技创新园北京市昌平区北七家镇，邮编102209
Email: hujie@ctbri.com.cn
Email: hujie@ctbri.com.cn